linux-toradex.git/drivers/dma-buf/dma-resv.c, branch v6.11 Linux kernel for Apalis and Colibri modules dma-buf: add a warning when drv try to reserve 0 fence slots 2024-05-31T08:12:52+00:00 Christian König ckoenig.leichtzumerken@gmail.com 2024-05-29T08:43:22+00:00 c9402efe492bb46ccbf94fedc4783eb8f8747567 When dma_resv_reserve_fences() is called with num_fences=0 it usually means that a driver or other component messed up its calculation how many fences are needed. Warn in that situation. When no fence are needed the function shouldn't be called in the first place. Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240529084322.2284-1-christian.koenig@amd.com Reviewed-by: Matthew Auld <matthew.auld@intel.com> 
When dma_resv_reserve_fences() is called with num_fences=0 it usually
means that a driver or other component messed up its calculation how
many fences are needed. Warn in that situation.

When no fence are needed the function shouldn't be called in the first
place.

Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240529084322.2284-1-christian.koenig@amd.com
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Merge drm/drm-next into drm-misc-next 2024-01-29T13:20:23+00:00 Maxime Ripard mripard@kernel.org 2024-01-29T13:20:23+00:00 4db102dcb0396a4ccf89b1eac0f4eb3fd167a080 Kickstart 6.9 development cycle. Signed-off-by: Maxime Ripard <mripard@kernel.org> 
Kickstart 6.9 development cycle.

Signed-off-by: Maxime Ripard <mripard@kernel.org>
dma-buf/dma-resv: fix spelling 2024-01-12T13:01:52+00:00 Randy Dunlap rdunlap@infradead.org 2024-01-11T04:11:55+00:00 f730d43afb216606bf91bec56ce9c9d96668128b Fix spelling mistakes as reported by codespell. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: Christian König <christian.koenig@amd.com> Cc: linaro-mm-sig@lists.linaro.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20240111041202.32011-1-rdunlap@infradead.org 
Fix spelling mistakes as reported by codespell.

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Christian König <christian.koenig@amd.com>
Cc: linaro-mm-sig@lists.linaro.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20240111041202.32011-1-rdunlap@infradead.org
dma-buf: fix check in dma_resv_add_fence 2023-11-27T19:00:47+00:00 Christian König christian.koenig@amd.com 2023-11-14T12:37:09+00:00 95ba893c9f4feb836ddce627efd0bb6af6667031 It's valid to add the same fence multiple times to a dma-resv object and we shouldn't need one extra slot for each. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Fixes: a3f7c10a269d5 ("dma-buf/dma-resv: check if the new fence is really later") Cc: stable@vger.kernel.org # v5.19+ Link: https://patchwork.freedesktop.org/patch/msgid/20231115093035.1889-1-christian.koenig@amd.com 
It's valid to add the same fence multiple times to a dma-resv object and
we shouldn't need one extra slot for each.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Fixes: a3f7c10a269d5 ("dma-buf/dma-resv: check if the new fence is really later")
Cc: stable@vger.kernel.org # v5.19+
Link: https://patchwork.freedesktop.org/patch/msgid/20231115093035.1889-1-christian.koenig@amd.com
dma-buf/dma-resv: Stop leaking on krealloc() failure 2023-07-15T11:57:30+00:00 Ville Syrjälä ville.syrjala@linux.intel.com 2023-07-13T19:47:45+00:00 05abb3be91d8788328231ee02973ab3d47f5e3d2 Currently dma_resv_get_fences() will leak the previously allocated array if the fence iteration got restarted and the krealloc_array() fails. Free the old array by hand, and make sure we still clear the returned *fences so the caller won't end up accessing freed memory. Some (but not all) of the callers of dma_resv_get_fences() seem to still trawl through the array even when dma_resv_get_fences() failed. And let's zero out *num_fences as well for good measure. Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Christian König <christian.koenig@amd.com> Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-sig@lists.linaro.org Fixes: d3c80698c9f5 ("dma-buf: use new iterator in dma_resv_get_fences v3") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20230713194745.1751-1-ville.syrjala@linux.intel.com Signed-off-by: Christian König <christian.koenig@amd.com> 
Currently dma_resv_get_fences() will leak the previously
allocated array if the fence iteration got restarted and
the krealloc_array() fails.

Free the old array by hand, and make sure we still clear
the returned *fences so the caller won't end up accessing
freed memory. Some (but not all) of the callers of
dma_resv_get_fences() seem to still trawl through the
array even when dma_resv_get_fences() failed. And let's
zero out *num_fences as well for good measure.

Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Christian König <christian.koenig@amd.com>
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-sig@lists.linaro.org
Fixes: d3c80698c9f5 ("dma-buf: use new iterator in dma_resv_get_fences v3")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20230713194745.1751-1-ville.syrjala@linux.intel.com
Signed-off-by: Christian König <christian.koenig@amd.com>
dma-buf/dma-resv.c: fix a typo 2023-04-17T06:24:31+00:00 Sui Jingfeng suijingfeng@loongson.cn 2023-04-16T14:38:49+00:00 e28f6966ac8021d8b677fe3839361db8c9344206 The dma_resv_wait_timeout() function return a value greater than zero on success. Signed-off-by: Sui Jingfeng <suijingfeng@loongson.cn> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230416143849.1142779-1-suijingfeng@loongson.cn 
The dma_resv_wait_timeout() function return a value greater than zero
on success.

Signed-off-by: Sui Jingfeng <suijingfeng@loongson.cn>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230416143849.1142779-1-suijingfeng@loongson.cn
dma-buf/dma-resv: Add a way to set fence deadline 2023-03-28T20:39:02+00:00 Rob Clark robdclark@chromium.org 2023-02-18T20:35:04+00:00 d7d5a21dd6b4706c04fbba5d25db8da5f25aab68 Add a way to set a deadline on remaining resv fences according to the requested usage. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Christian König <christian.koenig@amd.com> 
Add a way to set a deadline on remaining resv fences according to the
requested usage.

Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Christian König <christian.koenig@amd.com>
dma-buf: Proactively round up to kmalloc bucket size 2022-11-01T17:04:52+00:00 Kees Cook keescook@chromium.org 2022-10-18T09:10:11+00:00 cd536db050993f7c220a6cfb01de5356032b6f8e Instead of discovering the kmalloc bucket size _after_ allocation, round up proactively so the allocation is explicitly made for the full size, allowing the compiler to correctly reason about the resulting size of the buffer through the existing __alloc_size() hint. Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-sig@lists.linaro.org Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20221018090858.never.941-kees@kernel.org 
Instead of discovering the kmalloc bucket size _after_ allocation, round
up proactively so the allocation is explicitly made for the full size,
allowing the compiler to correctly reason about the resulting size of
the buffer through the existing __alloc_size() hint.

Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: linux-media@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-sig@lists.linaro.org
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20221018090858.never.941-kees@kernel.org
dma-buf/dma-resv: check if the new fence is really later 2022-08-25T11:10:30+00:00 Christian König ckoenig.leichtzumerken@gmail.com 2022-08-10T17:26:17+00:00 a3f7c10a269d5b77dd5822ade822643ced3057f0 Previously when we added a fence to a dma_resv object we always assumed the the newer than all the existing fences. With Jason's work to add an UAPI to explicit export/import that's not necessary the case any more. So without this check we would allow userspace to force the kernel into an use after free error. Since the change is very small and defensive it's probably a good idea to backport this to stable kernels as well just in case others are using the dma_resv object in the same way. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220810172617.140047-1-christian.koenig@amd.com Cc: stable@vger.kernel.org # v5.19+ 
Previously when we added a fence to a dma_resv object we always
assumed the the newer than all the existing fences.

With Jason's work to add an UAPI to explicit export/import that's not
necessary the case any more. So without this check we would allow
userspace to force the kernel into an use after free error.

Since the change is very small and defensive it's probably a good
idea to backport this to stable kernels as well just in case others
are using the dma_resv object in the same way.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220810172617.140047-1-christian.koenig@amd.com
Cc: stable@vger.kernel.org # v5.19+
dma-buf: Fix one use-after-free of fence 2022-07-07T08:24:59+00:00 xinhui pan xinhui.pan@amd.com 2022-07-07T08:02:41+00:00 7c1aeba7bb977fe327fbc9682e9ccb36134cbf77 Need get the new fence when we replace the old one. Fixes: 047a1b877ed48 ("dma-buf & drm/amdgpu: remove dma_resv workaround") Signed-off-by: xinhui pan <xinhui.pan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220707080241.20060-1-xinhui.pan@amd.com Signed-off-by: Christian König <christian.koenig@amd.com> 
Need get the new fence when we replace the old one.

Fixes: 047a1b877ed48 ("dma-buf & drm/amdgpu: remove dma_resv workaround")
Signed-off-by: xinhui pan <xinhui.pan@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220707080241.20060-1-xinhui.pan@amd.com
Signed-off-by: Christian König <christian.koenig@amd.com>