[PATCH v6 RESEND] dma-buf: system_heap: Add a size check for allocation

From: Guangming Add a size check for allocation since the allocation size should be always less than the total DRAM size on system heap. Adding this check can prevent comsuming too much time for invalid allocations. Signed-off-by: Guangming Acked-by: John Stultz --- drivers/dma-buf/heaps/syst

[PATCH v6] dma-buf: system_heap: Add a size check for allocation

From: Guangming Add a size check for allocation since the allocation size should be always less than the total DRAM size on system heap. Adding this check can prevent comsuming too much time for invalid allocations. Signed-off-by: Guangming --- drivers/dma-buf/heaps/system_heap.c | 8

[PATCH v5] dma-buf: system_heap: Add a size check for allocation

From: Guangming Add a size check for allocation since the allocation size should be always less than the total DRAM size on system heap. Adding this check can prevent comsuming too much time for invalid allocations. Signed-off-by: Guangming --- drivers/dma-buf/heaps/system_heap.c | 8

[PATCH v4] dma-buf: system_heap: Add a size check for allocation

From: Guangming Add a size check for allocation since the allocation size should be always less than the total DRAM size on system heap. And it can prevent consuming too much time for invalid allocations. Signed-off-by: Guangming --- drivers/dma-buf/heaps/system_heap.c | 7 +++ 1 file chan

[PATCH v3] dma-buf: dma-heap: Add a size check for allocation

From: Guangming Add a size check for allocation since the allocation size is always less than the total DRAM size. Without this check, once the invalid size allocation runs on a process that can't be killed by OOM flow(such as "gralloc" on Android devices), it will cause a kernel exception, and

Re: [PATCH v2] dma-buf: dma-heap: Add a size check for allocation

From: Guangming.Cao On Tue, 2022-01-04 at 08:47 +0100, Christian K鰊ig wrote: > Am 03.01.22 um 19:57 schrieb John Stultz: > > On Mon, Dec 27, 2021 at 1:52 AM wrote: > > > From: Guangming > > > > > > > Thanks for submitting this! > > > > &g

[PATCH v2] dma-buf: dma-heap: Add a size check for allocation

From: Guangming Add a size check for allcation since the allocation size is always less than the total DRAM size. Signed-off-by: Guangming Signed-off-by: jianjiao zeng --- v2: 1. update size limitation as total_dram page size. 2. update commit message --- drivers/dma-buf/dma-heap.c | 2 ++

[PATCH v2] dma-buf: dma-heap: Add a size check for allocation

From: Guangming Add a size check for allcation since the allocation size is always less than the total DRAM size. Signed-off-by: Guangming Signed-off-by: jianjiao zeng --- v2: 1. update size limitation as total_dram page size. 2. update commit message --- drivers/dma-buf/dma-heap.c | 2 ++

[PATCH] dma-buf: dma-heap: Add a size limitation for allocation

From: Guangming Currently, there is no size check for allocation. If the alloc size is larger than DRAM, it will cause OOM issue. Besides, if it runs on a process that won't be killed by OOM flow, it will cause a kernel exception finally, and we couldn't find the correct memory usage by dma-buf

[PATCH v4] dma-buf: system_heap: Use 'for_each_sgtable_sg' in pages free flow

From: Guangming For previous version, it uses 'sg_table.nent's to traverse sg_table in pages free flow. However, 'sg_table.nents' is reassigned in 'dma_map_sg', it means the number of created entries in the DMA adderess space. So, use 'sg_table.nents' in pages free flow will case some pages can't

[PATCH v3] dma-buf: system_heap: Use 'for_each_sgtable_sg' in pages free flow

From: Guangming For previous version, it uses 'sg_table.nent's to traverse sg_table in pages free flow. However, 'sg_table.nents' is reassigned in 'dma_map_sg', it means the number of created entries in the DMA adderess space. So, use 'sg_table.nents' in pages free flow will case some pages can't

[PATCH v2] dma_heap: use for_each_sgtable_sg in sg_table release flow

From: Guangming Use (for_each_sgtable_sg) rather than (for_each_sg) to traverse sg_table to free sg_table. Use (for_each_sg) maybe will casuse some pages can't be freed when send wrong nents number. Signed-off-by: Guangming --- drivers/dma-buf/heaps/system_heap.c | 2 +- 1 file changed, 1 inse

[PATCH] dma_heap: use sg_table.orig_nents in sg_table release flow

From: Guangming Use (sg_table.orig_nents) rather than (sg_table.nents) to traverse sg_table to free sg_table. Use (sg_table.nents) maybe will casuse some pages can't be freed. Signed-off-by: Guangming --- drivers/dma-buf/heaps/system_heap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH v2] dma-buf: acquire name lock before read/write dma_buf.name

From: Guangming Cao On Fri, 2021-10-08 at 12:24 +0200, Christian König wrote: > Am 08.10.21 um 09:54 schrieb guangming@mediatek.com: > > From: Guangming Cao > > > > Because dma-buf.name can be freed in func: "dma_buf_set_name", > > so, we need to acquire lock first before we read/write dma_

Re: [PATCH v3] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME

From: Guangming Cao On Tue, 2021-10-26 at 13:18 +0200, Christian König wrote: > Am 14.10.21 um 12:25 schrieb guangming@mediatek.com: > > From: Guangming Cao > > > > In this patch(https://patchwork.freedesktop.org/patch/310349), > > it add a new IOCTL to support dma-buf user to set debug nam

Re: [Linaro-mm-sig] [PATCH] dma-buf: add attachments empty check for dma_buf_release

From: Guangming Cao On Tue, 2021-10-19 at 23:11 +0200, Daniel Vetter wrote: > On Tue, Oct 19, 2021 at 05:37:27PM +0200, Christian K鰊ig wrote: > > > > > > Am 19.10.21 um 14:41 schrieb Daniel Vetter: > > > On Tue, Oct 19, 2021 at 08:23:45PM +0800, > > > guangming@mediatek.com wrote: > > > >

[PATCH v3] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME

From: Guangming Cao On Thu, 2021-10-14 at 18:25 +0800, guangming@mediatek.com wrote: > From: Guangming Cao > > In this patch(https://patchwork.freedesktop.org/patch/310349), > it add a new IOCTL to support dma-buf user to set debug name. > > But it also added a limitation of this IOCTL, it

[PATCH] dma-buf: add attachments empty check for dma_buf_release

From: Guangming Cao Since there is no mandatory inspection for attachments in dma_buf_release. There will be a case that dma_buf already released but attachment is still in use, which can points to the dmabuf, and it maybe cause some unexpected issues. With IOMMU, when this cases occurs, there w

Re: [PATCH] dma-buf: Add support for mapping buffers with DMA attributes

From: Guangming Cao On Tue, 2021-08-31 at 14:47 +0200, Daniel Vetter wrote: > On Mon, Aug 30, 2021 at 10:39:11AM +0800, guangming@mediatek.com > wrote: > > From: Guangming Cao > > > > When mapping the memory represented by a dma-buf into a device's > > address space, it might be desireable

[PATCH v3] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME

From: Guangming Cao On Wed, 2021-10-13 at 14:20 +0200, Christian König wrote: > Am 13.10.21 um 01:56 schrieb Sumit Semwal: > > Hello Guangming, Christian, > > > > > > > > On Tue, 12 Oct 2021, 14:09 , wrote: > > > From: Guangming Cao > > > > > > > Am 09.10.21 um 07:55 schrieb guangming@m

[PATCH v3] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME

From: Guangming Cao In this patch(https://patchwork.freedesktop.org/patch/310349), it add a new IOCTL to support dma-buf user to set debug name. But it also added a limitation of this IOCTL, it needs the attachments of dmabuf should be empty, otherwise it will fail. For the original series, the

Re: [PATCH v2] dma-buf: acquire name lock before read/write dma_buf.name

From: Guangming Cao > Am 08.10.21 um 09:54 schrieb guangming@mediatek.com: > > From: Guangming Cao > > > > Because dma-buf.name can be freed in func: "dma_buf_set_name", > > so, we need to acquire lock first before we read/write dma_buf.name > > to prevent Use After Free(UAF) issue. > > > >

Re: [PATCH v2] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME

From: Guangming Cao > Am 09.10.21 um 07:55 schrieb guangming@mediatek.com: > From: Guangming Cao > > > > If dma-buf don't want userspace users to touch the dmabuf buffer, > > it seems we should add this restriction into dma_buf_ops.mmap, > > not in this IOCTL:DMA_BUF_SET_NAME. > > > > With t

[PATCH v2] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME

From: Guangming Cao If dma-buf don't want userspace users to touch the dmabuf buffer, it seems we should add this restriction into dma_buf_ops.mmap, not in this IOCTL:DMA_BUF_SET_NAME. With this restriction, we can only know the kernel users of the dmabuf by attachments. However, for many usersp

[PATCH] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME

From: Guangming Cao If dma-buf don't want userspace users to touch the dmabuf buffer, it seems we should add this restriction into dma_buf_ops.mmap, not in this IOCTL:DMA_BUF_SET_NAME. With this restriction, we can only know the kernel users of the dmabuf by attachments. However, for many usersp

[PATCH v2] dma-buf: acquire name lock before read/write dma_buf.name

From: Guangming Cao Because dma-buf.name can be freed in func: "dma_buf_set_name", so, we need to acquire lock first before we read/write dma_buf.name to prevent Use After Free(UAF) issue. Signed-off-by: Guangming Cao --- drivers/dma-buf/dma-buf.c | 3 +++ 1 file changed, 3 insertions(+) diff

[PATCH v2] dma-buf: acquire name lock before read/write dma_buf.name

From: Guangming Cao Because dma-buf.name can be freed in func: "dma_buf_set_name", so, we need to acquire lock first before we read/write dma_buf.name to prevent Use After Free(UAF) issue. Signed-off-by: Guangming Cao --- drivers/dma-buf/dma-buf.c | 5 + 1 file changed, 5 insertions(+) di

[PATCH] dma-buf: acquire name lock before read/write dma_buf.name

From: Guangming Cao Because dma-buf.name can be freed in func: "dma_buf_set_name", so, we need to acquire lock first before we read/write dma_buf.name to prevent Use After Free(UAF) issue. Signed-off-by: Guangming Cao --- drivers/dma-buf/dma-buf.c | 5 + 1 file changed, 5 insertions(+) di

Re: [PATCH] dma-buf: heaps: remove duplicated cache sync

From: Guangming Cao > Am 30.08.21 um 12:01 schrieb guangming@mediatek.com: > > From: Guangming Cao > > > > Current flow, one dmabuf maybe call cache sync many times if > > it has beed mapped more than one time. > > Well I'm not an expert on DMA heaps, but this will most likely not work > co

[PATCH] dma-buf: heaps: remove duplicated cache sync

From: Guangming Cao Current flow, one dmabuf maybe call cache sync many times if it has beed mapped more than one time. Is there any case that attachments of one dmabuf will points to different memory? If not, seems do sync only one time is more better. Signed-off-by: Guangming Cao --- driver

[PATCH] dma-buf: Add support for mapping buffers with DMA attributes

From: Guangming Cao When mapping the memory represented by a dma-buf into a device's address space, it might be desireable to map the memory with certain DMA attributes. Thus, introduce the dma_mapping_attrs field in the dma_buf_attachment structure so that when the memory is mapped with dma_buf_

[PATCH] dma-buf: Add support for mapping buffers with DMA attributes

From: Guangming Cao When mapping the memory represented by a dma-buf into a device's address space, it might be desireable to map the memory with certain DMA attributes. Thus, introduce the dma_mapping_attrs field in the dma_buf_attachment structure so that when the memory is mapped with dma_buf_

[PATCH] dma_heap: enable map_attrs when (un)map_attachment

From: Guangming Cao For dma-heap users, they can't bypass cache sync when (un)map iova with dma heap. But they can do it by adding DMA_ATTR_SKIP_CPU_SYNC into dma_alloc_attrs. To Keep alignment, add map_attrs support for dma_heap when (un)map_attachment. Signed-off-by: Guangming Cao --- drive

[PATCH] dma-heap: Let dma heap use dma_map_attrs to map & unmap iova

From: Guangming Cao On Thu, 2021-07-15 at 14:24 +0800, guangming@mediatek.com wrote: > From: Guangming Cao > > On Thu, 2021-07-08 at 18:14 +0800, guangming@mediatek.com wrote: > > Hi Sumit, Christian, Matthias, > > gentle ping for this patch :) move receviers to '--to' list. gentle p

[PATCH v2] dma_buf: remove dmabuf sysfs teardown before release

From: Guangming Cao Dmabuf sysfs stat is used for dmabuf info track. But these file maybe still in use after buffer released, should clear it before buffer release. Signed-off-by: Guangming Cao --- drivers/dma-buf/dma-buf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dr

Re: [PATCH] dma_buf: remove dmabuf sysfs teardown before release/detach

From: Guangming Cao On Tue, 2021-07-20 at 11:31 +0200, Christian König wrote: > Am 19.07.21 um 07:19 schrieb guangming@mediatek.com: > > From: Guangming Cao > > > > Dmabuf sysfs stat is used for dmabuf info track. > > but these file maybe still use after buffer release/detach, > > should cl

[PATCH] dma_buf: remove dmabuf sysfs teardown before release/detach

From: Guangming Cao Dmabuf sysfs stat is used for dmabuf info track. but these file maybe still use after buffer release/detach, should clear it before buffer release/detach. Signed-off-by: Guangming Cao --- drivers/dma-buf/dma-buf.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)

[PATCH] dma-heap: Let dma heap use dma_map_attrs to map & unmap iova

From: Guangming Cao On Thu, 2021-07-08 at 18:14 +0800, guangming@mediatek.com wrote: Hi Sumit, Christian, Matthias, gentle ping for this patch :) BRs! Guangming > From: Guangming Cao > > For dma-heap users, they can't bypass cache sync when map/unmap iova > with dma heap. But they can d

Re: [PATCH] dma-buf: add kernel count for dma_buf

From: Guangming.Cao On Wed, 2021-07-14 at 14:28 +0200, Christian König wrote: > Am 14.07.21 um 14:03 schrieb guangming@mediatek.com: > > From: Guangming.Cao > > > > On Wed, 2021-07-14 at 12:43 +0200, Christian K鰊ig wrote: > > > Am 14.07.21 um 11:44 schr

[PATCH] dma-buf: support users to change dma_buf.name

From: Guangming Cao User space user can call DMA_BUF_SET_NAME to set dma_buf.name, also add a kernel api for users to do same thing at kernel side. Signed-off-by: Guangming Cao --- drivers/dma-buf/dma-buf.c | 28 ++-- include/linux/dma-buf.h | 1 + 2 files changed, 2

Re: [PATCH] dma-buf: add kernel count for dma_buf

From: Guangming.Cao On Wed, 2021-07-14 at 12:43 +0200, Christian K鰊ig wrote: > Am 14.07.21 um 11:44 schrieb guangming@mediatek.com: > > From: Guangming Cao > > > > On Wed, 2021-07-14 at 10:46 +0200, Christian K鰊ig wrote: > > > Am 14.07.21 um 09:11 schr

[PATCH] dma-buf: add kernel count for dma_buf

From: Guangming Cao Add a refcount for kernel to prevent UAF(Use After Free) issue. We can assume a case like below: 1. kernel space alloc dma_buf(file count = 1) 2. kernel use dma_buf to get fd(file count = 1) 3. userspace use fd to do mapping (file count = 2) 4. kernel call dma

[PATCH] dma-heap: Let dma heap use dma_map_attrs to map & unmap iova

From: Guangming Cao For dma-heap users, they can't bypass cache sync when map/unmap iova with dma heap. But they can do it by adding DMA_ATTR_SKIP_CPU_SYNC into dma_alloc_attrs. To keep alignment, at dma_heap side, also use dma_buf_attachment.dma_map_attrs to do iova map & unmap. Signed-off-by: