- Linaro-mm-sig - lists.linaro.org

Re: [PATCH] misc: fastrpc: avoid double fput() on failed usercopy

by Greg Kroah-Hartman

On Thu, Jan 27, 2022 at 02:24:29PM +0100, Greg Kroah-Hartman wrote: > On Thu, Jan 27, 2022 at 02:02:18PM +0100, Mathias Krause wrote: > > If the copy back to userland fails for the FASTRPC_IOCTL_ALLOC_DMA_BUFF > > ioctl(), we shouldn't assume that 'buf->dmabuf' is still valid. In fact, > > dma_buf_fd() called fd_install() before, i.e. "consumed" one reference, > > leaving us with none. > > > > Calling dma_buf_put() will therefore put a reference we no longer own, > > leading to a valid file descritor table entry for an already released > > 'file' object which is a straight use-after-free. > > > > Simply avoid calling dma_buf_put() and rely on the process exit code to > > do the necessary cleanup, if needed, i.e. if the file descriptor is > > still valid. > > > > Fixes: 6cffd79504ce ("misc: fastrpc: Add support for dmabuf exporter") > > Signed-off-by: Mathias Krause <minipli(a)grsecurity.net> > > --- > > drivers/misc/fastrpc.c | 9 ++++++++- > > 1 file changed, 8 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c > > index 4ccbf43e6bfa..aa1682b94a23 100644 > > --- a/drivers/misc/fastrpc.c > > +++ b/drivers/misc/fastrpc.c > > @@ -1288,7 +1288,14 @@ static int fastrpc_dmabuf_alloc(struct fastrpc_user *fl, char __user *argp) > > } > > > > if (copy_to_user(argp, &bp, sizeof(bp))) { > > - dma_buf_put(buf->dmabuf); > > + /* > > + * The usercopy failed, but we can't do much about it, as > > + * dma_buf_fd() already called fd_install() and made the > > + * file descriptor accessible for the current process. It > > + * might already be closed and dmabuf no longer valid when > > + * we reach this point. Therefore "leak" the fd and rely on > > + * the process exit path to do any required cleanup. > > + */ > > return -EFAULT; > > } > > > > This feels wrong. How do all other dma buf users handle this? > > And you forgot to cc: the dmabuf developers, I think get_maintainers.pl > should have caught them on this patch. Odd, it didn't, not your fault, my apologies. DMA BUFFER maintainers, what happened to the MAINTAINERS regex that caused the above patch to not catch you all? thanks, greg k-h

3 years, 4 months

2
1
0 0

[PATCH RFC 0/3] Add a module parameter to adjust kfence objects

by Peng Liu

This series make KFENCE to be more convenient to adjust parameters in not only debug process but also production situations. In different production and development stage, the demands of memory and CPU limitations for KFENCE is quite different. In order to satisfy these demands with a uniform kernel release, dynamically adjust KFENCE parameters is needed. Signed-off-by: Peng Liu <liupeng256(a)huawei.com> Peng Liu (3): kfence: Add a module parameter to adjust kfence objects kfence: Optimize branches prediction when sample interval is zero kfence: Make test case compatible with run time set sample interval Documentation/dev-tools/kfence.rst | 14 ++-- include/linux/kfence.h | 10 ++- mm/kfence/core.c | 113 ++++++++++++++++++++++++----- mm/kfence/kfence.h | 2 +- mm/kfence/kfence_test.c | 10 +-- 5 files changed, 116 insertions(+), 33 deletions(-) -- 2.18.0.huawei.25

3 years, 4 months

4
14
0 0

[PATCH] drm/msm: Fix wrong size calculation

by Xianting Tian

For example, memory-region in .dts as below, reg = <0x0 0x50000000 0x0 0x20000000> We can get below values, struct resource r; r.start = 0x50000000; r.end = 0x6fffffff; So the size should be: size = r.end - r.start + 1 = 0x20000000 Signed-off-by: Xianting Tian <xianting.tian(a)linux.alibaba.com> --- drivers/gpu/drm/msm/msm_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c index 892c04365..f04a2337d 100644 --- a/drivers/gpu/drm/msm/msm_drv.c +++ b/drivers/gpu/drm/msm/msm_drv.c @@ -466,7 +466,7 @@ static int msm_init_vram(struct drm_device *dev) of_node_put(node); if (ret) return ret; - size = r.end - r.start; + size = r.end - r.start + 1; DRM_INFO("using VRAM carveout: %lx@%pa\n", size, &r.start); /* if we have no IOMMU, then we need to use carveout allocator. -- 2.17.1

3 years, 4 months

2
1
0 0

[PATCH 5.4 027/320] dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled()

by Greg Kroah-Hartman

From: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> commit 95d35838880fb040ccb9fe4a48816bd0c8b62df5 upstream. If a dma_fence_array is reported signaled by a call to dma_fence_is_signaled(), it may leak the PENDING_ERROR status. Fix this by clearing the PENDING_ERROR status if we return true in dma_fence_array_signaled(). v2: - Update Cc list, and add R-b. Fixes: 1f70b8b812f3 ("dma-fence: Propagate errors to dma-fence-array container") Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Gustavo Padovan <gustavo(a)padovan.org> Cc: Christian König <christian.koenig(a)amd.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: <stable(a)vger.kernel.org> # v5.4+ Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211129152727.448908-1-thoma… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma-buf/dma-fence-array.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -104,7 +104,11 @@ static bool dma_fence_array_signaled(str { struct dma_fence_array *array = to_dma_fence_array(fence); - return atomic_read(&array->num_pending) <= 0; + if (atomic_read(&array->num_pending) > 0) + return false; + + dma_fence_array_clear_pending_error(array); + return true; } static void dma_fence_array_release(struct dma_fence *fence)

3 years, 4 months

1
0
0 0

[PATCH 5.10 035/563] dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled()

by Greg Kroah-Hartman

From: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> commit 95d35838880fb040ccb9fe4a48816bd0c8b62df5 upstream. If a dma_fence_array is reported signaled by a call to dma_fence_is_signaled(), it may leak the PENDING_ERROR status. Fix this by clearing the PENDING_ERROR status if we return true in dma_fence_array_signaled(). v2: - Update Cc list, and add R-b. Fixes: 1f70b8b812f3 ("dma-fence: Propagate errors to dma-fence-array container") Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Gustavo Padovan <gustavo(a)padovan.org> Cc: Christian König <christian.koenig(a)amd.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: <stable(a)vger.kernel.org> # v5.4+ Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211129152727.448908-1-thoma… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma-buf/dma-fence-array.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -104,7 +104,11 @@ static bool dma_fence_array_signaled(str { struct dma_fence_array *array = to_dma_fence_array(fence); - return atomic_read(&array->num_pending) <= 0; + if (atomic_read(&array->num_pending) > 0) + return false; + + dma_fence_array_clear_pending_error(array); + return true; } static void dma_fence_array_release(struct dma_fence *fence)

3 years, 4 months

1
0
0 0

[PATCH 5.15 068/846] dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled()

by Greg Kroah-Hartman

From: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> commit 95d35838880fb040ccb9fe4a48816bd0c8b62df5 upstream. If a dma_fence_array is reported signaled by a call to dma_fence_is_signaled(), it may leak the PENDING_ERROR status. Fix this by clearing the PENDING_ERROR status if we return true in dma_fence_array_signaled(). v2: - Update Cc list, and add R-b. Fixes: 1f70b8b812f3 ("dma-fence: Propagate errors to dma-fence-array container") Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Gustavo Padovan <gustavo(a)padovan.org> Cc: Christian König <christian.koenig(a)amd.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: <stable(a)vger.kernel.org> # v5.4+ Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211129152727.448908-1-thoma… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma-buf/dma-fence-array.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -104,7 +104,11 @@ static bool dma_fence_array_signaled(str { struct dma_fence_array *array = to_dma_fence_array(fence); - return atomic_read(&array->num_pending) <= 0; + if (atomic_read(&array->num_pending) > 0) + return false; + + dma_fence_array_clear_pending_error(array); + return true; } static void dma_fence_array_release(struct dma_fence *fence)

3 years, 4 months

1
0
0 0

[PATCH 5.16 0073/1039] dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled()

by Greg Kroah-Hartman

From: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> commit 95d35838880fb040ccb9fe4a48816bd0c8b62df5 upstream. If a dma_fence_array is reported signaled by a call to dma_fence_is_signaled(), it may leak the PENDING_ERROR status. Fix this by clearing the PENDING_ERROR status if we return true in dma_fence_array_signaled(). v2: - Update Cc list, and add R-b. Fixes: 1f70b8b812f3 ("dma-fence: Propagate errors to dma-fence-array container") Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Gustavo Padovan <gustavo(a)padovan.org> Cc: Christian König <christian.koenig(a)amd.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: <stable(a)vger.kernel.org> # v5.4+ Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211129152727.448908-1-thoma… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma-buf/dma-fence-array.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -104,7 +104,11 @@ static bool dma_fence_array_signaled(str { struct dma_fence_array *array = to_dma_fence_array(fence); - return atomic_read(&array->num_pending) <= 0; + if (atomic_read(&array->num_pending) > 0) + return false; + + dma_fence_array_clear_pending_error(array); + return true; } static void dma_fence_array_release(struct dma_fence *fence)

3 years, 4 months

1
0
0 0

Patch "dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled()" has been added to the 5.10-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled() to the 5.10-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dma_fence_array-fix-pending_error-leak-in-dma_fence_array_signaled.patch and it can be found in the queue-5.10 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. From 95d35838880fb040ccb9fe4a48816bd0c8b62df5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= <thomas.hellstrom(a)linux.intel.com> Date: Mon, 29 Nov 2021 16:27:27 +0100 Subject: dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> commit 95d35838880fb040ccb9fe4a48816bd0c8b62df5 upstream. If a dma_fence_array is reported signaled by a call to dma_fence_is_signaled(), it may leak the PENDING_ERROR status. Fix this by clearing the PENDING_ERROR status if we return true in dma_fence_array_signaled(). v2: - Update Cc list, and add R-b. Fixes: 1f70b8b812f3 ("dma-fence: Propagate errors to dma-fence-array container") Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Gustavo Padovan <gustavo(a)padovan.org> Cc: Christian König <christian.koenig(a)amd.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: <stable(a)vger.kernel.org> # v5.4+ Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211129152727.448908-1-thoma… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma-buf/dma-fence-array.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -104,7 +104,11 @@ static bool dma_fence_array_signaled(str { struct dma_fence_array *array = to_dma_fence_array(fence); - return atomic_read(&array->num_pending) <= 0; + if (atomic_read(&array->num_pending) > 0) + return false; + + dma_fence_array_clear_pending_error(array); + return true; } static void dma_fence_array_release(struct dma_fence *fence) Patches currently in stable-queue which might be from thomas.hellstrom(a)linux.intel.com are queue-5.10/dma_fence_array-fix-pending_error-leak-in-dma_fence_array_signaled.patch

3 years, 4 months

1
0
0 0

Patch "dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled()" has been added to the 5.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled() to the 5.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dma_fence_array-fix-pending_error-leak-in-dma_fence_array_signaled.patch and it can be found in the queue-5.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. From 95d35838880fb040ccb9fe4a48816bd0c8b62df5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= <thomas.hellstrom(a)linux.intel.com> Date: Mon, 29 Nov 2021 16:27:27 +0100 Subject: dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> commit 95d35838880fb040ccb9fe4a48816bd0c8b62df5 upstream. If a dma_fence_array is reported signaled by a call to dma_fence_is_signaled(), it may leak the PENDING_ERROR status. Fix this by clearing the PENDING_ERROR status if we return true in dma_fence_array_signaled(). v2: - Update Cc list, and add R-b. Fixes: 1f70b8b812f3 ("dma-fence: Propagate errors to dma-fence-array container") Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Gustavo Padovan <gustavo(a)padovan.org> Cc: Christian König <christian.koenig(a)amd.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: <stable(a)vger.kernel.org> # v5.4+ Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211129152727.448908-1-thoma… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma-buf/dma-fence-array.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -104,7 +104,11 @@ static bool dma_fence_array_signaled(str { struct dma_fence_array *array = to_dma_fence_array(fence); - return atomic_read(&array->num_pending) <= 0; + if (atomic_read(&array->num_pending) > 0) + return false; + + dma_fence_array_clear_pending_error(array); + return true; } static void dma_fence_array_release(struct dma_fence *fence) Patches currently in stable-queue which might be from thomas.hellstrom(a)linux.intel.com are queue-5.4/dma_fence_array-fix-pending_error-leak-in-dma_fence_array_signaled.patch

3 years, 4 months

1
0
0 0

Patch "dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled()" has been added to the 5.16-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled() to the 5.16-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dma_fence_array-fix-pending_error-leak-in-dma_fence_array_signaled.patch and it can be found in the queue-5.16 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. From 95d35838880fb040ccb9fe4a48816bd0c8b62df5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= <thomas.hellstrom(a)linux.intel.com> Date: Mon, 29 Nov 2021 16:27:27 +0100 Subject: dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> commit 95d35838880fb040ccb9fe4a48816bd0c8b62df5 upstream. If a dma_fence_array is reported signaled by a call to dma_fence_is_signaled(), it may leak the PENDING_ERROR status. Fix this by clearing the PENDING_ERROR status if we return true in dma_fence_array_signaled(). v2: - Update Cc list, and add R-b. Fixes: 1f70b8b812f3 ("dma-fence: Propagate errors to dma-fence-array container") Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Gustavo Padovan <gustavo(a)padovan.org> Cc: Christian König <christian.koenig(a)amd.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: <stable(a)vger.kernel.org> # v5.4+ Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211129152727.448908-1-thoma… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma-buf/dma-fence-array.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -104,7 +104,11 @@ static bool dma_fence_array_signaled(str { struct dma_fence_array *array = to_dma_fence_array(fence); - return atomic_read(&array->num_pending) <= 0; + if (atomic_read(&array->num_pending) > 0) + return false; + + dma_fence_array_clear_pending_error(array); + return true; } static void dma_fence_array_release(struct dma_fence *fence) Patches currently in stable-queue which might be from thomas.hellstrom(a)linux.intel.com are queue-5.16/dma_fence_array-fix-pending_error-leak-in-dma_fence_array_signaled.patch

3 years, 4 months

1
0
0 0

Patch "dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled()" has been added to the 5.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled() to the 5.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dma_fence_array-fix-pending_error-leak-in-dma_fence_array_signaled.patch and it can be found in the queue-5.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. From 95d35838880fb040ccb9fe4a48816bd0c8b62df5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= <thomas.hellstrom(a)linux.intel.com> Date: Mon, 29 Nov 2021 16:27:27 +0100 Subject: dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled() MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> commit 95d35838880fb040ccb9fe4a48816bd0c8b62df5 upstream. If a dma_fence_array is reported signaled by a call to dma_fence_is_signaled(), it may leak the PENDING_ERROR status. Fix this by clearing the PENDING_ERROR status if we return true in dma_fence_array_signaled(). v2: - Update Cc list, and add R-b. Fixes: 1f70b8b812f3 ("dma-fence: Propagate errors to dma-fence-array container") Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Gustavo Padovan <gustavo(a)padovan.org> Cc: Christian König <christian.koenig(a)amd.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linaro-mm-sig(a)lists.linaro.org Cc: <stable(a)vger.kernel.org> # v5.4+ Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211129152727.448908-1-thoma… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/dma-buf/dma-fence-array.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -104,7 +104,11 @@ static bool dma_fence_array_signaled(str { struct dma_fence_array *array = to_dma_fence_array(fence); - return atomic_read(&array->num_pending) <= 0; + if (atomic_read(&array->num_pending) > 0) + return false; + + dma_fence_array_clear_pending_error(array); + return true; } static void dma_fence_array_release(struct dma_fence *fence) Patches currently in stable-queue which might be from thomas.hellstrom(a)linux.intel.com are queue-5.15/dma_fence_array-fix-pending_error-leak-in-dma_fence_array_signaled.patch

3 years, 4 months

1
0
0 0

[PATCH] drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj

by Xin Xiong

This issue takes place in an error path in amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into default case, the function simply returns -EINVAL, forgetting to decrement the reference count of a dma_fence obj, which is bumped earlier by amdgpu_cs_get_fence(). This may result in reference count leaks. Fix it by decreasing the refcount of specific object before returning the error code. Signed-off-by: Xin Xiong <xiongx18(a)fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf(a)gmail.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c index 0311d799a..894869789 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c @@ -1510,6 +1510,7 @@ int amdgpu_cs_fence_to_handle_ioctl(struct drm_device *dev, void *data, return 0; default: + dma_fence_put(fence); return -EINVAL; } } -- 2.25.1

3 years, 4 months

3
2
0 0

Enforce dma_fence container rules

by Christian König

Hi Daniel, second version of this set. I've kept the fence ops exported for now since there are indeed valid uses in the drm_syncobj implementation which needs a more wider rework. But quite a bunch of cases in i915, one in amdgpu and another one in vmwgfx are cleaned up at the end of this series now. Please review and comment, Christian.

3 years, 4 months

3
14
0 0

[syzbot] WARNING in dma_map_sgtable

by syzbot

Hello, syzbot found the following issue on: HEAD commit: e3a8b6a1e70c Merge tag 'slab-for-5.17-part2' of git://git... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1507e01fb00000 kernel config: https://syzkaller.appspot.com/x/.config?x=73c17fd2d4a060fe dashboard link: https://syzkaller.appspot.com/bug?extid=d03b64357793677f0080 compiler: Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+d03b64357793677f0080(a)syzkaller.appspotmail.com ------------[ cut here ]------------ WARNING: CPU: 1 PID: 21150 at kernel/dma/mapping.c:188 __dma_map_sg_attrs kernel/dma/mapping.c:188 [inline] WARNING: CPU: 1 PID: 21150 at kernel/dma/mapping.c:188 dma_map_sgtable+0x203/0x260 kernel/dma/mapping.c:264 Modules linked in: CPU: 1 PID: 21150 Comm: syz-executor.5 Not tainted 5.16.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__dma_map_sg_attrs kernel/dma/mapping.c:188 [inline] RIP: 0010:dma_map_sgtable+0x203/0x260 kernel/dma/mapping.c:264 Code: 75 15 e8 50 b2 13 00 eb cb e8 49 b2 13 00 eb c4 e8 42 b2 13 00 eb bd e8 3b b2 13 00 0f 0b bd fb ff ff ff eb af e8 2d b2 13 00 <0f> 0b 31 ed 48 bb 00 00 00 00 00 fc ff df e9 7b ff ff ff 89 e9 80 RSP: 0018:ffffc9000969fd20 EFLAGS: 00010287 RAX: ffffffff8171ee13 RBX: dffffc0000000000 RCX: 0000000000040000 RDX: ffffc900056f9000 RSI: 000000000000079b RDI: 000000000000079c RBP: ffff888147437408 R08: ffffffff8171ece3 R09: ffffed100d4e6956 R10: ffffed100d4e6956 R11: 0000000000000000 R12: ffff888147437000 R13: ffff88806a734aa0 R14: 0000000000000000 R15: 0000000000000002 FS: 00007f009bbc7700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055555641b108 CR3: 000000001901b000 CR4: 00000000003506e0 DR0: 0000000020000100 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600 Call Trace: <TASK> get_sg_table+0xfc/0x150 drivers/dma-buf/udmabuf.c:72 begin_cpu_udmabuf+0xf5/0x160 drivers/dma-buf/udmabuf.c:126 dma_buf_begin_cpu_access+0xd8/0x170 drivers/dma-buf/dma-buf.c:1164 dma_buf_ioctl+0x2a0/0x2f0 drivers/dma-buf/dma-buf.c:363 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f009d251fe9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f009bbc7168 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f009d364f60 RCX: 00007f009d251fe9 RDX: 0000000020000040 RSI: 0000000040086200 RDI: 000000000000000b RBP: 00007f009d2ac08d R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc7751fd4f R14: 00007f009bbc7300 R15: 0000000000022000 </TASK> --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

3 years, 4 months

2
1
0 0

[PATCH 1/4] dma-buf: consolidate dma_fence subclass checking

by Christian König

Consolidate the wrapper functions to check for dma_fence subclasses in the dma_fence header. This makes it easier to document and also check the different requirements for fence containers in the subclasses. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- include/linux/dma-fence-array.h | 15 +------------ include/linux/dma-fence-chain.h | 3 +-- include/linux/dma-fence.h | 38 +++++++++++++++++++++++++++++++++ 3 files changed, 40 insertions(+), 16 deletions(-) diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h index 303dd712220f..fec374f69e12 100644 --- a/include/linux/dma-fence-array.h +++ b/include/linux/dma-fence-array.h @@ -45,19 +45,6 @@ struct dma_fence_array { struct irq_work work; }; -extern const struct dma_fence_ops dma_fence_array_ops; - -/** - * dma_fence_is_array - check if a fence is from the array subsclass - * @fence: fence to test - * - * Return true if it is a dma_fence_array and false otherwise. - */ -static inline bool dma_fence_is_array(struct dma_fence *fence) -{ - return fence->ops == &dma_fence_array_ops; -} - /** * to_dma_fence_array - cast a fence to a dma_fence_array * @fence: fence to cast to a dma_fence_array @@ -68,7 +55,7 @@ static inline bool dma_fence_is_array(struct dma_fence *fence) static inline struct dma_fence_array * to_dma_fence_array(struct dma_fence *fence) { - if (fence->ops != &dma_fence_array_ops) + if (!fence || !dma_fence_is_array(fence)) return NULL; return container_of(fence, struct dma_fence_array, base); diff --git a/include/linux/dma-fence-chain.h b/include/linux/dma-fence-chain.h index 54fe3443fd2c..ee906b659694 100644 --- a/include/linux/dma-fence-chain.h +++ b/include/linux/dma-fence-chain.h @@ -49,7 +49,6 @@ struct dma_fence_chain { spinlock_t lock; }; -extern const struct dma_fence_ops dma_fence_chain_ops; /** * to_dma_fence_chain - cast a fence to a dma_fence_chain @@ -61,7 +60,7 @@ extern const struct dma_fence_ops dma_fence_chain_ops; static inline struct dma_fence_chain * to_dma_fence_chain(struct dma_fence *fence) { - if (!fence || fence->ops != &dma_fence_chain_ops) + if (!fence || !dma_fence_is_chain(fence)) return NULL; return container_of(fence, struct dma_fence_chain, base); diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h index 1ea691753bd3..775cdc0b4f24 100644 --- a/include/linux/dma-fence.h +++ b/include/linux/dma-fence.h @@ -587,4 +587,42 @@ struct dma_fence *dma_fence_get_stub(void); struct dma_fence *dma_fence_allocate_private_stub(void); u64 dma_fence_context_alloc(unsigned num); +extern const struct dma_fence_ops dma_fence_array_ops; +extern const struct dma_fence_ops dma_fence_chain_ops; + +/** + * dma_fence_is_array - check if a fence is from the array subclass + * @fence: the fence to test + * + * Return true if it is a dma_fence_array and false otherwise. + */ +static inline bool dma_fence_is_array(struct dma_fence *fence) +{ + return fence->ops == &dma_fence_array_ops; +} + +/** + * dma_fence_is_chain - check if a fence is from the chain subclass + * @fence: the fence to test + * + * Return true if it is a dma_fence_chain and false otherwise. + */ +static inline bool dma_fence_is_chain(struct dma_fence *fence) +{ + return fence->ops == &dma_fence_chain_ops; +} + +/** + * dma_fence_is_container - check if a fence is a container for other fences + * @fence: the fence to test + * + * Return true if this fence is a container for other fences, false otherwise. + * This is important since we can't build up large fence structure or otherwise + * we run into recursion during operation on those fences. + */ +static inline bool dma_fence_is_container(struct dma_fence *fence) +{ + return dma_fence_is_array(fence) || dma_fence_is_chain(fence); +} + #endif /* __LINUX_DMA_FENCE_H */ -- 2.25.1

3 years, 4 months

2
9
0 0

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

by John Stultz

On Mon, Dec 27, 2021 at 1:52 AM <guangming.cao(a)mediatek.com> wrote: > > From: Guangming <Guangming.Cao(a)mediatek.com> > Thanks for submitting this! > Add a size check for allcation since the allocation size is nit: "allocation" above. > always less than the total DRAM size. In general, it might be good to add more context to the commit message to better answer *why* this change is needed rather than what the change is doing. ie: What negative thing happens without this change? And so how does this change avoid or improve things? > Signed-off-by: Guangming <Guangming.Cao(a)mediatek.com> > Signed-off-by: jianjiao zeng <jianjiao.zeng(a)mediatek.com> > --- > v2: 1. update size limitation as total_dram page size. > 2. update commit message > --- > drivers/dma-buf/dma-heap.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c > index 56bf5ad01ad5..e39d2be98d69 100644 > --- a/drivers/dma-buf/dma-heap.c > +++ b/drivers/dma-buf/dma-heap.c > @@ -55,6 +55,8 @@ static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len, > struct dma_buf *dmabuf; > int fd; > > + if (len / PAGE_SIZE > totalram_pages()) > + return -EINVAL; This seems sane. I know ION used to have some 1/2 of memory cap to avoid unnecessary memory pressure on crazy allocations. Could you send again with an improved commit message? thanks -john

3 years, 4 months

6
21
0 0

[RFC 0/6] Proposal for a GPU cgroup controller

by Hridya Valsaraju

This patch series revisits the proposal for a GPU cgroup controller to track and limit memory allocations by various device/allocator subsystems. The patch series also contains a simple prototype to illustrate how Android intends to implement DMA-BUF allocator attribution using the GPU cgroup controller. The prototype does not include resource limit enforcements. History of the GPU cgroup controller ==================================== The GPU/DRM cgroup controller came into being when a consensus[1] was reached that the resources it tracked were unsuitable to be integrated into memcg. Originally, the proposed controller was specific to the DRM subsystem and was intended to track GEM buffers and GPU-specific resources[2]. In order to help establish a unified memory accounting model for all GPU and all related subsystems, Daniel Vetter put forth a suggestion to move it out of the DRM subsystem so that it can be used by other DMA-BUF exporters as well[3]. This RFC proposes an interface that does the same. [1]: https://patchwork.kernel.org/project/dri-devel/cover/20190501140438.9506-1-… [2]: https://lore.kernel.org/amd-gfx/20210126214626.16260-1-brian.welty@intel.co… [3]: https://lore.kernel.org/amd-gfx/YCVOl8%2F87bqRSQei@phenom.ffwll.local/ Hridya Valsaraju (6): gpu: rfc: Proposal for a GPU cgroup controller cgroup: gpu: Add a cgroup controller for allocator attribution of GPU memory dmabuf: heaps: Use the GPU cgroup charge/uncharge APIs dma-buf: Add DMA-BUF exporter op to charge a DMA-BUF to a cgroup. dmabuf: system_heap: implement dma-buf op for GPU cgroup charge transfer android: binder: Add a buffer flag to relinquish ownership of fds Documentation/gpu/rfc/gpu-cgroup.rst | 192 +++++++++++++++++ Documentation/gpu/rfc/index.rst | 4 + drivers/android/binder.c | 32 +++ drivers/dma-buf/dma-heap.c | 27 +++ drivers/dma-buf/heaps/system_heap.c | 68 ++++++ include/linux/cgroup_gpu.h | 120 +++++++++++ include/linux/cgroup_subsys.h | 4 + include/linux/dma-buf.h | 18 ++ include/linux/dma-heap.h | 11 + include/uapi/linux/android/binder.h | 1 + init/Kconfig | 7 + kernel/cgroup/Makefile | 1 + kernel/cgroup/gpu.c | 305 +++++++++++++++++++++++++++ 13 files changed, 790 insertions(+) create mode 100644 Documentation/gpu/rfc/gpu-cgroup.rst create mode 100644 include/linux/cgroup_gpu.h create mode 100644 kernel/cgroup/gpu.c -- 2.34.1.703.g22d0c6ccf7-goog

3 years, 4 months

4
13
0 0

[PATCH] dma-buf: cma_heap: Fix mutex locking section

by Weizhao Ouyang

Fix cma_heap_buffer mutex locking critical section to protect vmap_cnt and vaddr. Fixes: a5d2d29e24be ("dma-buf: heaps: Move heap-helper logic into the cma_heap implementation") Signed-off-by: Weizhao Ouyang <o451686892(a)gmail.com> --- drivers/dma-buf/heaps/cma_heap.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c index 0c05b79870f9..83f02bd51dda 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -124,10 +124,11 @@ static int cma_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf, struct cma_heap_buffer *buffer = dmabuf->priv; struct dma_heap_attachment *a; + mutex_lock(&buffer->lock); + if (buffer->vmap_cnt) invalidate_kernel_vmap_range(buffer->vaddr, buffer->len); - mutex_lock(&buffer->lock); list_for_each_entry(a, &buffer->attachments, list) { if (!a->mapped) continue; @@ -144,10 +145,11 @@ static int cma_heap_dma_buf_end_cpu_access(struct dma_buf *dmabuf, struct cma_heap_buffer *buffer = dmabuf->priv; struct dma_heap_attachment *a; + mutex_lock(&buffer->lock); + if (buffer->vmap_cnt) flush_kernel_vmap_range(buffer->vaddr, buffer->len); - mutex_lock(&buffer->lock); list_for_each_entry(a, &buffer->attachments, list) { if (!a->mapped) continue; -- 2.32.0

3 years, 4 months

4
3
0 0

[PATCH] udmabuf: validate ubuf->pagecount

by Pavel Skripkin

Syzbot has reported GPF in sg_alloc_append_table_from_pages(). The problem was in ubuf->pages == ZERO_PTR. ubuf->pagecount is calculated from arguments passed from user-space. If user creates udmabuf with list.size == 0 then ubuf->pagecount will be also equal to zero; it causes kmalloc_array() to return ZERO_PTR. Fix it by validating ubuf->pagecount before passing it to kmalloc_array(). Fixes: fbb0de795078 ("Add udmabuf misc device") Reported-and-tested-by: syzbot+2c56b725ec547fa9cb29(a)syzkaller.appspotmail.com Signed-off-by: Pavel Skripkin <paskripkin(a)gmail.com> --- Happy New Year and Merry Christmas! :) With regards, Pavel Skripkin --- drivers/dma-buf/udmabuf.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index c57a609db75b..e7330684d3b8 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -190,6 +190,10 @@ static long udmabuf_create(struct miscdevice *device, if (ubuf->pagecount > pglimit) goto err; } + + if (!ubuf->pagecount) + goto err; + ubuf->pages = kmalloc_array(ubuf->pagecount, sizeof(*ubuf->pages), GFP_KERNEL); if (!ubuf->pages) { -- 2.34.1

3 years, 4 months

3
3
0 0

[PATCH 0/2] MAINTAINERS: update various stm & sti maintainer names

by Philippe Cornu

This short serie contains the maintainer status update sent recently by Benjamin Gaignard (see [1] for details) and add new maintainers for various stm & sti files. [1] https://lore.kernel.org/lkml/20210706163033.795805-1-benjamin.gaignard@coll… Benjamin Gaignard (1): MAINTAINERS: Update Benjamin Gaignard maintainer status Philippe Cornu (1): MAINTAINERS: update drm/stm drm/sti and cec/sti maintainers MAINTAINERS | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.17.1

3 years, 4 months

5
7
0 0

[PATCH] dma-buf: Move sysfs work out of DMA-BUF export/release path

by Hridya Valsaraju

Recently, we noticed an issue where a process went into direct reclaim while holding the kernfs rw semaphore for sysfs in write(exclusive) mode. This caused processes who were doing DMA-BUF exports and releases to go into uninterruptible sleep since they needed to acquire the same semaphore for the DMA-BUF sysfs entry creation/deletion. In order to avoid blocking DMA-BUF export/release for an indeterminate amount of time while another process is holding the sysfs rw semaphore in exclusive mode, this patch moves the per-buffer sysfs file creation/deleteion to a kthread. Fixes: bdb8d06dfefd ("dmabuf: Add the capability to expose DMA-BUF stats in sysfs") Signed-off-by: Hridya Valsaraju <hridya(a)google.com> --- drivers/dma-buf/dma-buf-sysfs-stats.c | 343 ++++++++++++++++++++++++-- include/linux/dma-buf.h | 46 ++++ 2 files changed, 366 insertions(+), 23 deletions(-) diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c b/drivers/dma-buf/dma-buf-sysfs-stats.c index 053baadcada9..3251fdf2f05f 100644 --- a/drivers/dma-buf/dma-buf-sysfs-stats.c +++ b/drivers/dma-buf/dma-buf-sysfs-stats.c @@ -7,13 +7,39 @@ #include <linux/dma-buf.h> #include <linux/dma-resv.h> +#include <linux/freezer.h> #include <linux/kobject.h> +#include <linux/kthread.h> +#include <linux/list.h> #include <linux/printk.h> +#include <linux/sched/signal.h> #include <linux/slab.h> #include <linux/sysfs.h> #include "dma-buf-sysfs-stats.h" +struct dmabuf_kobj_work { + struct list_head list; + struct dma_buf_sysfs_entry *sysfs_entry; + struct dma_buf_sysfs_entry_metadata *sysfs_metadata; + unsigned long uid; +}; + +/* Both kobject setup and teardown work gets queued on the list. */ +static LIST_HEAD(dmabuf_kobj_work_list); + +/* dmabuf_kobj_list_lock protects dmabuf_kobj_work_list. */ +static DEFINE_SPINLOCK(dmabuf_kobj_list_lock); + +/* + * dmabuf_sysfs_show_lock prevents a race between a DMA-BUF sysfs file being + * read and the DMA-BUF being freed by protecting sysfs_entry->dmabuf. + */ +static DEFINE_SPINLOCK(dmabuf_sysfs_show_lock); + +static struct task_struct *dmabuf_kobject_task; +static wait_queue_head_t dmabuf_kobject_waitqueue; + #define to_dma_buf_entry_from_kobj(x) container_of(x, struct dma_buf_sysfs_entry, kobj) /** @@ -64,15 +90,26 @@ static ssize_t dma_buf_stats_attribute_show(struct kobject *kobj, struct dma_buf_stats_attribute *attribute; struct dma_buf_sysfs_entry *sysfs_entry; struct dma_buf *dmabuf; + int ret; attribute = to_dma_buf_stats_attr(attr); sysfs_entry = to_dma_buf_entry_from_kobj(kobj); + + /* + * acquire dmabuf_sysfs_show_lock to prevent a race with the DMA-BUF + * being freed while sysfs_entry->dmabuf is being accessed. + */ + spin_lock(&dmabuf_sysfs_show_lock); dmabuf = sysfs_entry->dmabuf; - if (!dmabuf || !attribute->show) + if (!dmabuf || !attribute->show) { + spin_unlock(&dmabuf_sysfs_show_lock); return -EIO; + } - return attribute->show(dmabuf, attribute, buf); + ret = attribute->show(dmabuf, attribute, buf); + spin_unlock(&dmabuf_sysfs_show_lock); + return ret; } static const struct sysfs_ops dma_buf_stats_sysfs_ops = { @@ -118,33 +155,275 @@ static struct kobj_type dma_buf_ktype = { .default_groups = dma_buf_stats_default_groups, }; -void dma_buf_stats_teardown(struct dma_buf *dmabuf) +/* Statistics files do not need to send uevents. */ +static int dmabuf_sysfs_uevent_filter(struct kset *kset, struct kobject *kobj) { - struct dma_buf_sysfs_entry *sysfs_entry; + return 0; +} - sysfs_entry = dmabuf->sysfs_entry; - if (!sysfs_entry) - return; +static const struct kset_uevent_ops dmabuf_sysfs_no_uevent_ops = { + .filter = dmabuf_sysfs_uevent_filter, +}; + +/* setup of sysfs entries done asynchronously in the worker thread. */ +static void dma_buf_sysfs_stats_setup_work(struct dmabuf_kobj_work *kobject_work) +{ + struct dma_buf_sysfs_entry *sysfs_entry = kobject_work->sysfs_entry; + struct dma_buf_sysfs_entry_metadata *sysfs_metadata = + kobject_work->sysfs_metadata; + bool free_metadata = false; + + int ret = kobject_init_and_add(&sysfs_entry->kobj, &dma_buf_ktype, NULL, + "%lu", kobject_work->uid); + if (ret) { + kobject_put(&sysfs_entry->kobj); + + spin_lock(&sysfs_metadata->sysfs_entry_lock); + if (sysfs_metadata->status == SYSFS_ENTRY_INIT_ABORTED) { + /* + * SYSFS_ENTRY_INIT_ABORTED means that the DMA-BUF has already + * been freed. At this point, its safe to free the memory for + * the sysfs_metadata; + */ + free_metadata = true; + } else { + /* + * The DMA-BUF has not yet been freed, set the status to + * sysfs_entry_error so that when the DMA-BUF gets + * freed, we know there is no need to teardown the sysfs + * entry. + */ + sysfs_metadata->status = SYSFS_ENTRY_ERROR; + } + goto unlock; + } + + /* + * If the DMA-BUF has not yet been released, status would still be + * SYSFS_ENTRY_INIT_IN_PROGRESS. We set the status as initialized. + */ + spin_lock(&sysfs_metadata->sysfs_entry_lock); + if (sysfs_metadata->status == SYSFS_ENTRY_INIT_IN_PROGRESS) { + sysfs_metadata->status = SYSFS_ENTRY_INITIALIZED; + goto unlock; + } + /* + * At this point the status is SYSFS_ENTRY_INIT_ABORTED which means + * that the DMA-BUF has already been freed. Hence, we cleanup the + * sysfs_entry and its metadata since neither of them are needed + * anymore. + */ + free_metadata = true; kobject_del(&sysfs_entry->kobj); kobject_put(&sysfs_entry->kobj); + +unlock: + spin_unlock(&sysfs_metadata->sysfs_entry_lock); + if (free_metadata) { + kfree(kobject_work->sysfs_metadata); + kobject_work->sysfs_metadata = NULL; + } } +/* teardown of sysfs entries done asynchronously in the worker thread. */ +static void dma_buf_sysfs_stats_teardown_work(struct dmabuf_kobj_work *kobject_work) +{ + struct dma_buf_sysfs_entry *sysfs_entry = kobject_work->sysfs_entry; -/* Statistics files do not need to send uevents. */ -static int dmabuf_sysfs_uevent_filter(struct kset *kset, struct kobject *kobj) + kobject_del(&sysfs_entry->kobj); + kobject_put(&sysfs_entry->kobj); + + kfree(kobject_work->sysfs_metadata); + kobject_work->sysfs_metadata = NULL; +} + +/* do setup or teardown of sysfs entries as required */ +static void do_kobject_work(struct dmabuf_kobj_work *kobject_work) { + struct dma_buf_sysfs_entry_metadata *sysfs_metadata; + bool setup_needed = false; + bool teardown_needed = false; + + sysfs_metadata = kobject_work->sysfs_metadata; + spin_lock(&sysfs_metadata->sysfs_entry_lock); + if (sysfs_metadata->status == SYSFS_ENTRY_UNINITIALIZED) { + setup_needed = true; + sysfs_metadata->status = SYSFS_ENTRY_INIT_IN_PROGRESS; + } else if (sysfs_metadata->status == SYSFS_ENTRY_INITIALIZED) { + teardown_needed = true; + } + + /* + * It is ok to release the sysfs_entry_lock here. + * + * If setup_needed is true, we check the status again after the kobject + * initialization to see if it has been set to SYSFS_ENTRY_INIT_ABORTED + * and if so teardown the kobject. + * + * If teardown_needed is true, there are no more changes expected to the + * status. + * + * If neither setup_needed nor teardown needed are true, it + * means the DMA-BUF was freed before we got around to setting up the + * sysfs entry and hence we just need to release the metadata and + * return. + */ + spin_unlock(&kobject_work->sysfs_metadata->sysfs_entry_lock); + + if (setup_needed) + dma_buf_sysfs_stats_setup_work(kobject_work); + else if (teardown_needed) + dma_buf_sysfs_stats_teardown_work(kobject_work); + else + kfree(kobject_work->sysfs_metadata); + + kfree(kobject_work); +} + +static struct dmabuf_kobj_work *get_next_kobj_work(void) +{ + struct dmabuf_kobj_work *kobject_work; + + spin_lock(&dmabuf_kobj_list_lock); + kobject_work = list_first_entry_or_null(&dmabuf_kobj_work_list, + struct dmabuf_kobj_work, list); + if (kobject_work) + list_del(&kobject_work->list); + spin_unlock(&dmabuf_kobj_list_lock); + return kobject_work; +} + +static int kobject_work_thread(void *data) +{ + struct dmabuf_kobj_work *kobject_work; + + while (1) { + wait_event_freezable(dmabuf_kobject_waitqueue, + (kobject_work = get_next_kobj_work())); + do_kobject_work(kobject_work); + } + return 0; } -static const struct kset_uevent_ops dmabuf_sysfs_no_uevent_ops = { - .filter = dmabuf_sysfs_uevent_filter, -}; +static int kobject_worklist_init(void) +{ + init_waitqueue_head(&dmabuf_kobject_waitqueue); + dmabuf_kobject_task = kthread_run(kobject_work_thread, NULL, + "%s", "dmabuf-kobject-worker"); + if (IS_ERR(dmabuf_kobject_task)) { + pr_err("Creating thread for deferred sysfs entry creation/deletion failed\n"); + return PTR_ERR(dmabuf_kobject_task); + } + sched_set_normal(dmabuf_kobject_task, MAX_NICE); + + return 0; +} + +static void deferred_kobject_create(struct dmabuf_kobj_work *kobject_work) +{ + INIT_LIST_HEAD(&kobject_work->list); + + spin_lock(&dmabuf_kobj_list_lock); + + list_add_tail(&kobject_work->list, &dmabuf_kobj_work_list); + + spin_unlock(&dmabuf_kobj_list_lock); + + wake_up(&dmabuf_kobject_waitqueue); +} + + +void dma_buf_stats_teardown(struct dma_buf *dmabuf) +{ + struct dma_buf_sysfs_entry *sysfs_entry; + struct dma_buf_sysfs_entry_metadata *sysfs_metadata; + struct dmabuf_kobj_work *kobj_work; + + sysfs_entry = dmabuf->sysfs_entry; + if (!sysfs_entry) + return; + + sysfs_metadata = dmabuf->sysfs_entry_metadata; + if (!sysfs_metadata) + return; + + spin_lock(&sysfs_metadata->sysfs_entry_lock); + + if (sysfs_metadata->status == SYSFS_ENTRY_UNINITIALIZED || + sysfs_metadata->status == SYSFS_ENTRY_INIT_IN_PROGRESS) { + /* + * The sysfs entry for this buffer has not yet been initialized, + * we set the status to SYSFS_ENTRY_INIT_ABORTED to abort the + * initialization. + */ + sysfs_metadata->status = SYSFS_ENTRY_INIT_ABORTED; + spin_unlock(&sysfs_metadata->sysfs_entry_lock); + + /* + * In case kobject initialization completes right as we release + * the sysfs_entry_lock, disable show() for the sysfs entry by + * setting sysfs_entry->dmabuf to NULL to prevent a race. + */ + spin_lock(&dmabuf_sysfs_show_lock); + sysfs_entry->dmabuf = NULL; + spin_unlock(&dmabuf_sysfs_show_lock); + + return; + } + + if (sysfs_metadata->status == SYSFS_ENTRY_INITIALIZED) { + /* + * queue teardown work only if sysfs_entry is fully inititalized. + * It is ok to release the sysfs_entry_lock here since the + * status can no longer change. + */ + spin_unlock(&sysfs_metadata->sysfs_entry_lock); + + /* + * Meanwhile disable show() for the sysfs entry to avoid a race + * between teardown and show(). + */ + spin_lock(&dmabuf_sysfs_show_lock); + sysfs_entry->dmabuf = NULL; + spin_unlock(&dmabuf_sysfs_show_lock); + + kobj_work = kzalloc(sizeof(struct dmabuf_kobj_work), GFP_KERNEL); + if (!kobj_work) { + /* do the teardown immediately. */ + kobject_del(&sysfs_entry->kobj); + kobject_put(&sysfs_entry->kobj); + kfree(sysfs_metadata); + } else { + /* queue teardown work. */ + kobj_work->sysfs_entry = dmabuf->sysfs_entry; + kobj_work->sysfs_metadata = dmabuf->sysfs_entry_metadata; + deferred_kobject_create(kobj_work); + } + + return; + } + + /* + * status is SYSFS_ENTRY_INIT_ERROR so we only need to free the + * metadata. + */ + spin_unlock(&sysfs_metadata->sysfs_entry_lock); + kfree(dmabuf->sysfs_entry_metadata); + dmabuf->sysfs_entry_metadata = NULL; +} static struct kset *dma_buf_stats_kset; static struct kset *dma_buf_per_buffer_stats_kset; int dma_buf_init_sysfs_statistics(void) { + int ret; + + ret = kobject_worklist_init(); + if (ret) + return ret; + dma_buf_stats_kset = kset_create_and_add("dmabuf", &dmabuf_sysfs_no_uevent_ops, kernel_kobj); @@ -171,7 +450,8 @@ void dma_buf_uninit_sysfs_statistics(void) int dma_buf_stats_setup(struct dma_buf *dmabuf) { struct dma_buf_sysfs_entry *sysfs_entry; - int ret; + struct dma_buf_sysfs_entry_metadata *sysfs_metadata; + struct dmabuf_kobj_work *kobj_work; if (!dmabuf || !dmabuf->file) return -EINVAL; @@ -188,18 +468,35 @@ int dma_buf_stats_setup(struct dma_buf *dmabuf) sysfs_entry->kobj.kset = dma_buf_per_buffer_stats_kset; sysfs_entry->dmabuf = dmabuf; + sysfs_metadata = kzalloc(sizeof(struct dma_buf_sysfs_entry_metadata), + GFP_KERNEL); + if (!sysfs_metadata) { + kfree(sysfs_entry); + return -ENOMEM; + } + dmabuf->sysfs_entry = sysfs_entry; - /* create the directory for buffer stats */ - ret = kobject_init_and_add(&sysfs_entry->kobj, &dma_buf_ktype, NULL, - "%lu", file_inode(dmabuf->file)->i_ino); - if (ret) - goto err_sysfs_dmabuf; + sysfs_metadata->status = SYSFS_ENTRY_UNINITIALIZED; + spin_lock_init(&sysfs_metadata->sysfs_entry_lock); - return 0; + dmabuf->sysfs_entry_metadata = sysfs_metadata; -err_sysfs_dmabuf: - kobject_put(&sysfs_entry->kobj); - dmabuf->sysfs_entry = NULL; - return ret; + kobj_work = kzalloc(sizeof(struct dmabuf_kobj_work), GFP_KERNEL); + if (!kobj_work) { + kfree(sysfs_entry); + kfree(sysfs_metadata); + return -ENOMEM; + } + + kobj_work->sysfs_entry = dmabuf->sysfs_entry; + kobj_work->sysfs_metadata = dmabuf->sysfs_entry_metadata; + /* + * stash the inode number in struct dmabuf_kobj_work since setup + * might race with DMA-BUF teardown. + */ + kobj_work->uid = file_inode(dmabuf->file)->i_ino; + + deferred_kobject_create(kobj_work); + return 0; } diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index 7ab50076e7a6..0597690023a0 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -287,6 +287,50 @@ struct dma_buf_ops { void (*vunmap)(struct dma_buf *dmabuf, struct dma_buf_map *map); }; +#ifdef CONFIG_DMABUF_SYSFS_STATS +enum sysfs_entry_status { + SYSFS_ENTRY_UNINITIALIZED, + SYSFS_ENTRY_INIT_IN_PROGRESS, + SYSFS_ENTRY_ERROR, + SYSFS_ENTRY_INIT_ABORTED, + SYSFS_ENTRY_INITIALIZED, +}; + +/* + * struct dma_buf_sysfs_entry_metadata - Holds the current status for the + * DMA-BUF sysfs entry. + * + * @status: holds the current status for the DMA-BUF sysfs entry. The status of + * the sysfs entry has the following path. + * + * SYSFS_ENTRY_UNINITIALIZED + * __________________|____________________ + * | | + * SYSFS_ENTRY_INIT_IN_PROGRESS SYSFS_ENTRY_INIT_ABORTED (DMA-BUF + * | gets freed + * | before + * | init) + * ________|_____________________________________ + * | | | + * SYSFS_ENTRY_INITIALIZED | SYSFS_ENTRY_INIT_ABORTED + * | (DMA-BUF gets freed during kobject + * | init) + * | + * | + * SYSFS_ENTRY_ERROR + * (error during kobject init) + * + * @sysfs_entry_lock: protects access to @status. + */ +struct dma_buf_sysfs_entry_metadata { + enum sysfs_entry_status status; + /* + * Protects sysfs_entry_metadata->status + */ + spinlock_t sysfs_entry_lock; +}; +#endif + /** * struct dma_buf - shared buffer object * @@ -452,6 +496,8 @@ struct dma_buf { struct kobject kobj; struct dma_buf *dmabuf; } *sysfs_entry; + + struct dma_buf_sysfs_entry_metadata *sysfs_entry_metadata; #endif }; -- 2.34.1.448.ga2b2bfdf31-goog

3 years, 4 months

4
14
0 0

Re: [PATCH RESEND] dma-buf: heaps: Fix mutex lock area and generalize struct dma_heap_attachment

by John Stultz

On Tue, Dec 28, 2021 at 11:09 PM Weizhao Ouyang <o451686892(a)gmail.com> wrote: > > Fix cma_heap_buffer mutex lock area to protect vmap_cnt and vaddr. And > move struct dma_heap_attachment to dma-heap.h so that vendor dma heaps > can use it, the same behaviour as struct dma_buf_attachment. > Hey! Thanks for submitting this patch! Apologies for the slow reply (was out for the holidays). This patch is combining two changes in one patch, so they need to be split up. The locking change looks sane, but moving the dma_heap_attachment may need some extra justification as changing upstream code just to support out of tree code isn't usually done (if there was some benefit to the in-tree code, that would be fine though). I'd also be eager to try to get the vendor heap to be merged, assuming we can also merge an upstream user for it. thanks -john

3 years, 5 months

2
1
0 0

Re: [syzbot] general protection fault in sg_alloc_append_table_from_pages

by Pavel Skripkin

On 10/13/21 19:51, syzbot wrote: > Hello, > > syzbot found the following issue on: > > HEAD commit: 717478d89fe2 Merge tag 'riscv-for-linus-5.15-rc5' of git:/.. > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=12489abf300000 > kernel config: https://syzkaller.appspot.com/x/.config?x=32e6048063923b7b > dashboard link: https://syzkaller.appspot.com/bug?extid=2c56b725ec547fa9cb29 > compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2 > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=167b9e4f300000 > > The issue was bisected to: > > commit 284562e1f34874e267d4f499362c3816f8f6bc3f > Author: Gurchetan Singh <gurchetansingh(a)chromium.org> > Date: Tue Dec 3 01:36:27 2019 +0000 > > udmabuf: implement begin_cpu_access/end_cpu_access hooks > > bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12d68447300000 > final oops: https://syzkaller.appspot.com/x/report.txt?x=11d68447300000 > console output: https://syzkaller.appspot.com/x/log.txt?x=16d68447300000 > zero ubuf->pagecount will cause kmalloc_array() to return ZERO_PTR, that is unsafe to deref #syz test git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master With regards, Pavel Skripkin

3 years, 5 months

2
1
0 0

Re: [Linaro-mm-sig] [PATCH] udmabuf: put dmabuf in case of get fd failed

by kernel test robot

Hi Xianting, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [also build test ERROR on v5.16-rc6 next-20211217] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Xianting-Tian/udmabuf-put-dmabuf-i… base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git a7904a538933c525096ca2ccde1e60d0ee62c08e config: arc-randconfig-r043-20211220 (https://download.01.org/0day-ci/archive/20211220/202112202101.tVpymGaH-lkp@…) compiler: arceb-elf-gcc (GCC) 11.2.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/322781a4da9de4a3057afd933108d23ca7f… git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Xianting-Tian/udmabuf-put-dmabuf-in-case-of-get-fd-failed/20211220-134433 git checkout 322781a4da9de4a3057afd933108d23ca7f5282e # save the config file to linux build tree mkdir build_dir COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=arc SHELL=/bin/bash drivers/dma-buf/ If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp(a)intel.com> All error/warnings (new ones prefixed by >>): drivers/dma-buf/udmabuf.c: In function 'udmabuf_create': >> drivers/dma-buf/udmabuf.c:292:13: error: invalid storage class for function 'udmabuf_ioctl_create' 292 | static long udmabuf_ioctl_create(struct file *filp, unsigned long arg) | ^~~~~~~~~~~~~~~~~~~~ >> drivers/dma-buf/udmabuf.c:292:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] 292 | static long udmabuf_ioctl_create(struct file *filp, unsigned long arg) | ^~~~~~ >> drivers/dma-buf/udmabuf.c:311:13: error: invalid storage class for function 'udmabuf_ioctl_create_list' 311 | static long udmabuf_ioctl_create_list(struct file *filp, unsigned long arg) | ^~~~~~~~~~~~~~~~~~~~~~~~~ >> drivers/dma-buf/udmabuf.c:332:13: error: invalid storage class for function 'udmabuf_ioctl' 332 | static long udmabuf_ioctl(struct file *filp, unsigned int ioctl, | ^~~~~~~~~~~~~ >> drivers/dma-buf/udmabuf.c:353:27: error: initializer element is not constant 353 | .unlocked_ioctl = udmabuf_ioctl, | ^~~~~~~~~~~~~ drivers/dma-buf/udmabuf.c:353:27: note: (near initialization for 'udmabuf_fops.unlocked_ioctl') >> drivers/dma-buf/udmabuf.c:365:19: error: invalid storage class for function 'udmabuf_dev_init' 365 | static int __init udmabuf_dev_init(void) | ^~~~~~~~~~~~~~~~ >> drivers/dma-buf/udmabuf.c:370:20: error: invalid storage class for function 'udmabuf_dev_exit' 370 | static void __exit udmabuf_dev_exit(void) | ^~~~~~~~~~~~~~~~ In file included from include/linux/cred.h:12, from drivers/dma-buf/udmabuf.c:2: drivers/dma-buf/udmabuf.c:375:13: error: initializer element is not constant 375 | module_init(udmabuf_dev_init) | ^~~~~~~~~~~~~~~~ include/linux/init.h:250:55: note: in definition of macro '____define_initcall' 250 | __attribute__((__section__(__sec))) = fn; | ^~ include/linux/init.h:260:9: note: in expansion of macro '__unique_initcall' 260 | __unique_initcall(fn, id, __sec, __initcall_id(fn)) | ^~~~~~~~~~~~~~~~~ include/linux/init.h:262:35: note: in expansion of macro '___define_initcall' 262 | #define __define_initcall(fn, id) ___define_initcall(fn, id, .initcall##id) | ^~~~~~~~~~~~~~~~~~ include/linux/init.h:291:41: note: in expansion of macro '__define_initcall' 291 | #define device_initcall(fn) __define_initcall(fn, 6) | ^~~~~~~~~~~~~~~~~ include/linux/init.h:296:24: note: in expansion of macro 'device_initcall' 296 | #define __initcall(fn) device_initcall(fn) | ^~~~~~~~~~~~~~~ include/linux/module.h:88:25: note: in expansion of macro '__initcall' 88 | #define module_init(x) __initcall(x); | ^~~~~~~~~~ drivers/dma-buf/udmabuf.c:375:1: note: in expansion of macro 'module_init' 375 | module_init(udmabuf_dev_init) | ^~~~~~~~~~~ drivers/dma-buf/udmabuf.c:376:13: error: initializer element is not constant 376 | module_exit(udmabuf_dev_exit) | ^~~~~~~~~~~~~~~~ include/linux/init.h:299:57: note: in definition of macro '__exitcall' 299 | static exitcall_t __exitcall_##fn __exit_call = fn | ^~ drivers/dma-buf/udmabuf.c:376:1: note: in expansion of macro 'module_exit' 376 | module_exit(udmabuf_dev_exit) | ^~~~~~~~~~~ >> include/linux/init.h:299:9: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] 299 | static exitcall_t __exitcall_##fn __exit_call = fn | ^~~~~~ include/linux/module.h:100:25: note: in expansion of macro '__exitcall' 100 | #define module_exit(x) __exitcall(x); | ^~~~~~~~~~ drivers/dma-buf/udmabuf.c:376:1: note: in expansion of macro 'module_exit' 376 | module_exit(udmabuf_dev_exit) | ^~~~~~~~~~~ >> drivers/dma-buf/udmabuf.c:379:1: error: expected declaration or statement at end of input 379 | MODULE_LICENSE("GPL v2"); | ^~~~~~~~~~~~~~ vim +/udmabuf_ioctl_create +292 drivers/dma-buf/udmabuf.c fbb0de795078190 Gerd Hoffmann 2018-08-27 291 fbb0de795078190 Gerd Hoffmann 2018-08-27 @292 static long udmabuf_ioctl_create(struct file *filp, unsigned long arg) fbb0de795078190 Gerd Hoffmann 2018-08-27 293 { fbb0de795078190 Gerd Hoffmann 2018-08-27 294 struct udmabuf_create create; fbb0de795078190 Gerd Hoffmann 2018-08-27 295 struct udmabuf_create_list head; fbb0de795078190 Gerd Hoffmann 2018-08-27 296 struct udmabuf_create_item list; fbb0de795078190 Gerd Hoffmann 2018-08-27 297 fbb0de795078190 Gerd Hoffmann 2018-08-27 298 if (copy_from_user(&create, (void __user *)arg, 33f35429fc49c09 Gerd Hoffmann 2018-09-11 299 sizeof(create))) fbb0de795078190 Gerd Hoffmann 2018-08-27 300 return -EFAULT; fbb0de795078190 Gerd Hoffmann 2018-08-27 301 fbb0de795078190 Gerd Hoffmann 2018-08-27 302 head.flags = create.flags; fbb0de795078190 Gerd Hoffmann 2018-08-27 303 head.count = 1; fbb0de795078190 Gerd Hoffmann 2018-08-27 304 list.memfd = create.memfd; fbb0de795078190 Gerd Hoffmann 2018-08-27 305 list.offset = create.offset; fbb0de795078190 Gerd Hoffmann 2018-08-27 306 list.size = create.size; fbb0de795078190 Gerd Hoffmann 2018-08-27 307 c1bbed668997268 Gurchetan Singh 2019-12-02 308 return udmabuf_create(filp->private_data, &head, &list); fbb0de795078190 Gerd Hoffmann 2018-08-27 309 } fbb0de795078190 Gerd Hoffmann 2018-08-27 310 fbb0de795078190 Gerd Hoffmann 2018-08-27 @311 static long udmabuf_ioctl_create_list(struct file *filp, unsigned long arg) fbb0de795078190 Gerd Hoffmann 2018-08-27 312 { fbb0de795078190 Gerd Hoffmann 2018-08-27 313 struct udmabuf_create_list head; fbb0de795078190 Gerd Hoffmann 2018-08-27 314 struct udmabuf_create_item *list; fbb0de795078190 Gerd Hoffmann 2018-08-27 315 int ret = -EINVAL; fbb0de795078190 Gerd Hoffmann 2018-08-27 316 u32 lsize; fbb0de795078190 Gerd Hoffmann 2018-08-27 317 fbb0de795078190 Gerd Hoffmann 2018-08-27 318 if (copy_from_user(&head, (void __user *)arg, sizeof(head))) fbb0de795078190 Gerd Hoffmann 2018-08-27 319 return -EFAULT; dc4716d75154b36 Gerd Hoffmann 2018-09-11 320 if (head.count > list_limit) fbb0de795078190 Gerd Hoffmann 2018-08-27 321 return -EINVAL; fbb0de795078190 Gerd Hoffmann 2018-08-27 322 lsize = sizeof(struct udmabuf_create_item) * head.count; fbb0de795078190 Gerd Hoffmann 2018-08-27 323 list = memdup_user((void __user *)(arg + sizeof(head)), lsize); fbb0de795078190 Gerd Hoffmann 2018-08-27 324 if (IS_ERR(list)) fbb0de795078190 Gerd Hoffmann 2018-08-27 325 return PTR_ERR(list); fbb0de795078190 Gerd Hoffmann 2018-08-27 326 c1bbed668997268 Gurchetan Singh 2019-12-02 327 ret = udmabuf_create(filp->private_data, &head, list); fbb0de795078190 Gerd Hoffmann 2018-08-27 328 kfree(list); fbb0de795078190 Gerd Hoffmann 2018-08-27 329 return ret; fbb0de795078190 Gerd Hoffmann 2018-08-27 330 } fbb0de795078190 Gerd Hoffmann 2018-08-27 331 fbb0de795078190 Gerd Hoffmann 2018-08-27 @332 static long udmabuf_ioctl(struct file *filp, unsigned int ioctl, fbb0de795078190 Gerd Hoffmann 2018-08-27 333 unsigned long arg) fbb0de795078190 Gerd Hoffmann 2018-08-27 334 { fbb0de795078190 Gerd Hoffmann 2018-08-27 335 long ret; fbb0de795078190 Gerd Hoffmann 2018-08-27 336 fbb0de795078190 Gerd Hoffmann 2018-08-27 337 switch (ioctl) { fbb0de795078190 Gerd Hoffmann 2018-08-27 338 case UDMABUF_CREATE: fbb0de795078190 Gerd Hoffmann 2018-08-27 339 ret = udmabuf_ioctl_create(filp, arg); fbb0de795078190 Gerd Hoffmann 2018-08-27 340 break; fbb0de795078190 Gerd Hoffmann 2018-08-27 341 case UDMABUF_CREATE_LIST: fbb0de795078190 Gerd Hoffmann 2018-08-27 342 ret = udmabuf_ioctl_create_list(filp, arg); fbb0de795078190 Gerd Hoffmann 2018-08-27 343 break; fbb0de795078190 Gerd Hoffmann 2018-08-27 344 default: 52499d9cdd88784 Gerd Hoffmann 2018-09-11 345 ret = -ENOTTY; fbb0de795078190 Gerd Hoffmann 2018-08-27 346 break; fbb0de795078190 Gerd Hoffmann 2018-08-27 347 } fbb0de795078190 Gerd Hoffmann 2018-08-27 348 return ret; fbb0de795078190 Gerd Hoffmann 2018-08-27 349 } fbb0de795078190 Gerd Hoffmann 2018-08-27 350 fbb0de795078190 Gerd Hoffmann 2018-08-27 351 static const struct file_operations udmabuf_fops = { fbb0de795078190 Gerd Hoffmann 2018-08-27 352 .owner = THIS_MODULE, fbb0de795078190 Gerd Hoffmann 2018-08-27 @353 .unlocked_ioctl = udmabuf_ioctl, d4a197f4047e01d Kristian H. Kristensen 2020-09-03 354 #ifdef CONFIG_COMPAT d4a197f4047e01d Kristian H. Kristensen 2020-09-03 355 .compat_ioctl = udmabuf_ioctl, d4a197f4047e01d Kristian H. Kristensen 2020-09-03 356 #endif fbb0de795078190 Gerd Hoffmann 2018-08-27 357 }; fbb0de795078190 Gerd Hoffmann 2018-08-27 358 fbb0de795078190 Gerd Hoffmann 2018-08-27 359 static struct miscdevice udmabuf_misc = { fbb0de795078190 Gerd Hoffmann 2018-08-27 360 .minor = MISC_DYNAMIC_MINOR, fbb0de795078190 Gerd Hoffmann 2018-08-27 361 .name = "udmabuf", fbb0de795078190 Gerd Hoffmann 2018-08-27 362 .fops = &udmabuf_fops, fbb0de795078190 Gerd Hoffmann 2018-08-27 363 }; fbb0de795078190 Gerd Hoffmann 2018-08-27 364 fbb0de795078190 Gerd Hoffmann 2018-08-27 @365 static int __init udmabuf_dev_init(void) fbb0de795078190 Gerd Hoffmann 2018-08-27 366 { fbb0de795078190 Gerd Hoffmann 2018-08-27 367 return misc_register(&udmabuf_misc); fbb0de795078190 Gerd Hoffmann 2018-08-27 368 } fbb0de795078190 Gerd Hoffmann 2018-08-27 369 fbb0de795078190 Gerd Hoffmann 2018-08-27 @370 static void __exit udmabuf_dev_exit(void) fbb0de795078190 Gerd Hoffmann 2018-08-27 371 { fbb0de795078190 Gerd Hoffmann 2018-08-27 372 misc_deregister(&udmabuf_misc); fbb0de795078190 Gerd Hoffmann 2018-08-27 373 } fbb0de795078190 Gerd Hoffmann 2018-08-27 374 fbb0de795078190 Gerd Hoffmann 2018-08-27 375 module_init(udmabuf_dev_init) fbb0de795078190 Gerd Hoffmann 2018-08-27 376 module_exit(udmabuf_dev_exit) fbb0de795078190 Gerd Hoffmann 2018-08-27 377 fbb0de795078190 Gerd Hoffmann 2018-08-27 378 MODULE_AUTHOR("Gerd Hoffmann <kraxel(a)redhat.com>"); fbb0de795078190 Gerd Hoffmann 2018-08-27 @379 MODULE_LICENSE("GPL v2"); --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

3 years, 5 months

1
0
0 0

Re: [Linaro-mm-sig] [PATCH] udmabuf: put dmabuf in case of get fd failed

by kernel test robot

Hi Xianting, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v5.16-rc6 next-20211217] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Xianting-Tian/udmabuf-put-dmabuf-i… base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git a7904a538933c525096ca2ccde1e60d0ee62c08e config: x86_64-randconfig-r024-20211220 (https://download.01.org/0day-ci/archive/20211220/202112202114.4rnU3YZF-lkp@…) compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 555eacf75f21cd1dfc6363d73ad187b730349543) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/0day-ci/linux/commit/322781a4da9de4a3057afd933108d23ca7f… git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Xianting-Tian/udmabuf-put-dmabuf-in-case-of-get-fd-failed/20211220-134433 git checkout 322781a4da9de4a3057afd933108d23ca7f5282e # save the config file to linux build tree mkdir build_dir COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/dma-buf/ If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp(a)intel.com> All warnings (new ones prefixed by >>): drivers/dma-buf/udmabuf.c:293:1: error: function definition is not allowed here { ^ drivers/dma-buf/udmabuf.c:312:1: error: function definition is not allowed here { ^ drivers/dma-buf/udmabuf.c:334:1: error: function definition is not allowed here { ^ drivers/dma-buf/udmabuf.c:353:20: error: use of undeclared identifier 'udmabuf_ioctl' .unlocked_ioctl = udmabuf_ioctl, ^ drivers/dma-buf/udmabuf.c:355:20: error: use of undeclared identifier 'udmabuf_ioctl' .compat_ioctl = udmabuf_ioctl, ^ drivers/dma-buf/udmabuf.c:366:1: error: function definition is not allowed here { ^ drivers/dma-buf/udmabuf.c:371:1: error: function definition is not allowed here { ^ drivers/dma-buf/udmabuf.c:375:13: error: use of undeclared identifier 'udmabuf_dev_init' module_init(udmabuf_dev_init) ^ drivers/dma-buf/udmabuf.c:375:13: error: use of undeclared identifier 'udmabuf_dev_init' drivers/dma-buf/udmabuf.c:376:13: error: use of undeclared identifier 'udmabuf_dev_exit' module_exit(udmabuf_dev_exit) ^ drivers/dma-buf/udmabuf.c:379:26: error: expected '}' MODULE_LICENSE("GPL v2"); ^ drivers/dma-buf/udmabuf.c:166:1: note: to match this '{' { ^ >> drivers/dma-buf/udmabuf.c:351:37: warning: ISO C90 forbids mixing declarations and code [-Wdeclaration-after-statement] static const struct file_operations udmabuf_fops = { ^ 1 warning and 11 errors generated. vim +351 drivers/dma-buf/udmabuf.c fbb0de79507819 Gerd Hoffmann 2018-08-27 350 fbb0de79507819 Gerd Hoffmann 2018-08-27 @351 static const struct file_operations udmabuf_fops = { fbb0de79507819 Gerd Hoffmann 2018-08-27 352 .owner = THIS_MODULE, fbb0de79507819 Gerd Hoffmann 2018-08-27 353 .unlocked_ioctl = udmabuf_ioctl, d4a197f4047e01 Kristian H. Kristensen 2020-09-03 354 #ifdef CONFIG_COMPAT d4a197f4047e01 Kristian H. Kristensen 2020-09-03 355 .compat_ioctl = udmabuf_ioctl, d4a197f4047e01 Kristian H. Kristensen 2020-09-03 356 #endif fbb0de79507819 Gerd Hoffmann 2018-08-27 357 }; fbb0de79507819 Gerd Hoffmann 2018-08-27 358 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

3 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig