kernel/linux.git/drivers/dma-buf, branch v5.15.212

udmabuf: fix DMA direction mismatch in release_udmabuf()

2026-07-24T13:51:25+00:00

commit fb7b1a0ab25a6077d26cb3829e31743972d4f31d upstream. begin_cpu_udmabuf() maps the sg_table with the caller-provided direction (e.g., DMA_TO_DEVICE for a write-only sync), and caches it in ubuf->sg for reuse. However, release_udmabuf() always unmaps this sg_table with a hardcoded DMA_BIDIRECTIONAL, regardless of the direction that was originally used for the mapping. With CONFIG_DMA_API_DEBUG=y this produces: DMA-API: misc udmabuf: device driver frees DMA memory with different direction [device address=0x000000044a123000] [size=4096 bytes] [mapped with DMA_TO_DEVICE] [unmapped with DMA_BIDIRECTIONAL] The issue was found during video playback when GStreamer performed a write-only DMA_BUF_IOCTL_SYNC on a udmabuf. It can be reproduced with CONFIG_DMA_API_DEBUG=y by creating a udmabuf from a memfd, performing a write-only sync (DMA_BUF_SYNC_WRITE without DMA_BUF_SYNC_READ), and closing the file descriptor. Fix this by storing the DMA direction used when the sg_table is first created in begin_cpu_udmabuf(), and passing that same direction to put_sg_table() in release_udmabuf(). Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks") Cc: stable@vger.kernel.org Signed-off-by: Mikhail Gavrilov Reviewed-by: Vivek Kasireddy Signed-off-by: Vivek Kasireddy Link: https://patch.msgid.link/20260314232722.15555-1-mikhail.v.gavrilov@gmail.com Signed-off-by: Greg Kroah-Hartman

dma-buf: remove unused dma-fence-unwrap.c (stable/linux-5.15.y only)

2026-07-24T13:51:15+00:00

The file drivers/dma-buf/dma-fence-unwrap.c was incorrectly added to the 5.15.y stable branch in commit 4e82b9c11d3c ("dma-buf: add dma_fence_timestamp helper") as a new file, but it was never enabled in the Makefile, and its header include/linux/dma-fence-unwrap.h was not present, making it uncompilable. A full revert of commit 4e82b9c11d3c ("dma-buf: add dma_fence_timestamp helper") is not desirable because that commit also introduced the valid dma_fence_timestamp() helper and fixed legitimate timestamp race windows in drivers/dma-buf/sync_file.c and drivers/gpu/drm/scheduler/sched_main.c. Since there are no users of dma-fence-unwrap in the 5.15.y branch, remove the unused file to clean up the tree and avoid confusion. Fixes: 4e82b9c11d3c ("dma-buf: add dma_fence_timestamp helper") Signed-off-by: Tudor Ambarus Signed-off-by: Sasha Levin

dma-buf: insert memory barrier before updating num_fences

2025-09-09T16:50:23+00:00

[ Upstream commit 72c7d62583ebce7baeb61acce6057c361f73be4a ] smp_store_mb() inserts memory barrier after storing operation. It is different with what the comment is originally aiming so Null pointer dereference can be happened if memory update is reordered. Signed-off-by: Hyejeong Choi Fixes: a590d0fdbaa5 ("dma-buf: Update reservation shared_count after adding the new fence") CC: stable@vger.kernel.org Reviewed-by: Christian König Link: https://lore.kernel.org/r/20250513020638.GA2329653@au1-maretx-p37.eng.sarc.samsung.com Signed-off-by: Christian König [ adjusted `fobj->num_fences` to `fobj->shared_count` ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

dma-buf: fix timeout handling in dma_resv_wait_timeout v2

2025-07-17T16:30:52+00:00

[ Upstream commit 2b95a7db6e0f75587bffddbb490399cbb87e4985 ] Even the kerneldoc says that with a zero timeout the function should not wait for anything, but still return 1 to indicate that the fences are signaled now. Unfortunately that isn't what was implemented, instead of only returning 1 we also waited for at least one jiffies. Fix that by adjusting the handling to what the function is actually documented to do. v2: improve code readability Reported-by: Marek Olšák Reported-by: Lucas Stach Signed-off-by: Christian König Reviewed-by: Lucas Stach Cc: Link: https://lore.kernel.org/r/20250129105841.1806-1-christian.koenig@amd.com Signed-off-by: Sasha Levin

dma-buf: use new iterator in dma_resv_wait_timeout

2025-07-17T16:30:52+00:00

[ Upstream commit ada5c48b11a3df814701daa9cd11305a75a5f1a5 ] This makes the function much simpler since the complex retry logic is now handled elsewhere. Signed-off-by: Christian König Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20211005113742.1101-7-christian.koenig@amd.com Stable-dep-of: 2b95a7db6e0f ("dma-buf: fix timeout handling in dma_resv_wait_timeout v2") Signed-off-by: Sasha Levin

dma-buf: add dma_resv_for_each_fence_unlocked v8

2025-07-17T16:30:52+00:00

[ Upstream commit c921ff373b469ad7907cde219fa700909f59cac4 ] Abstract the complexity of iterating over all the fences in a dma_resv object. The new loop handles the whole RCU and retry dance and returns only fences where we can be sure we grabbed the right one. v2: fix accessing the shared fences while they might be freed, improve kerneldoc, rename _cursor to _iter, add dma_resv_iter_is_exclusive, add dma_resv_iter_begin/end v3: restructor the code, move rcu_read_lock()/unlock() into the iterator, add dma_resv_iter_is_restarted() v4: fix NULL deref when no explicit fence exists, drop superflous rcu_read_lock()/unlock() calls. v5: fix typos in the documentation v6: fix coding error when excl fence is NULL v7: one more logic fix v8: fix index check in dma_resv_iter_is_exclusive() Signed-off-by: Christian König Reviewed-by: Tvrtko Ursulin (v7) Link: https://patchwork.freedesktop.org/patch/msgid/20211005113742.1101-2-christian.koenig@amd.com Stable-dep-of: 2b95a7db6e0f ("dma-buf: fix timeout handling in dma_resv_wait_timeout v2") Signed-off-by: Sasha Levin

udmabuf: use sgtable-based scatterlist wrappers

2025-06-27T10:05:34+00:00

commit afe382843717d44b24ef5014d57dcbaab75a4052 upstream. Use common wrappers operating directly on the struct sg_table objects to fix incorrect use of scatterlists sync calls. dma_sync_sg_for_*() functions have to be called with the number of elements originally passed to dma_map_sg_*() function, not the one returned in sgtable's nents. Fixes: 1ffe09590121 ("udmabuf: fix dma-buf cpu access") CC: stable@vger.kernel.org Signed-off-by: Marek Szyprowski Acked-by: Vivek Kasireddy Reviewed-by: Christian König Signed-off-by: Christian König Link: https://lore.kernel.org/r/20250507160913.2084079-3-m.szyprowski@samsung.com Signed-off-by: Greg Kroah-Hartman

udmabuf: fix a buf size overflow issue during udmabuf creation

2025-05-02T05:44:36+00:00

[ Upstream commit 021ba7f1babd029e714d13a6bf2571b08af96d0f ] by casting size_limit_mb to u64 when calculate pglimit. Signed-off-by: Xiaogang Chen Link: https://patchwork.freedesktop.org/patch/msgid/20250321164126.329638-1-xiaogang.chen@amd.com Signed-off-by: Christian König Signed-off-by: Sasha Levin

udmabuf: also check for F_SEAL_FUTURE_WRITE

2025-01-09T12:28:35+00:00

commit 0a16e24e34f28210f68195259456c73462518597 upstream. When F_SEAL_FUTURE_WRITE was introduced, it was overlooked that udmabuf must reject memfds with this flag, just like ones with F_SEAL_WRITE. Fix it by adding F_SEAL_FUTURE_WRITE to SEALS_DENIED. Fixes: ab3948f58ff8 ("mm/memfd: add an F_SEAL_FUTURE_WRITE seal to memfd") Cc: stable@vger.kernel.org Acked-by: Vivek Kasireddy Signed-off-by: Jann Horn Reviewed-by: Joel Fernandes (Google) Signed-off-by: Vivek Kasireddy Link: https://patchwork.freedesktop.org/patch/msgid/20241204-udmabuf-fixes-v2-2-23887289de1c@google.com Signed-off-by: Greg Kroah-Hartman

dma-buf: fix dma_fence_array_signaled v4

2024-12-14T18:51:33+00:00

commit 78ac1c3558810486d90aa533b0039aa70487a3da upstream. The function silently assumed that signaling was already enabled for the dma_fence_array. This meant that without enabling signaling first we would never see forward progress. Fix that by falling back to testing each individual fence when signaling isn't enabled yet. v2: add the comment suggested by Boris why this is done this way v3: fix the underflow pointed out by Tvrtko v4: atomic_read_acquire() as suggested by Tvrtko Signed-off-by: Christian König Reviewed-by: Boris Brezillon Tested-by: Chia-I Wu Reviewed-by: Tvrtko Ursulin Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12094 Cc: Link: https://patchwork.freedesktop.org/patch/msgid/20241112121925.18464-1-christian.koenig@amd.com Signed-off-by: Greg Kroah-Hartman