kernel/git/stable/linux.git/drivers/dma-buf, branch linux-5.15.y

udmabuf: Ensure to perform cache synchronisation in begin_cpu_udmabuf()

2026-08-23T12:17:31+00:00

commit 1d0e25c1ddf2063c499264fb2ba0fa6a3e4f8a00 upstream. The message of commit 504e2b4ab97a ("dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning") says: > The CPU sync at map/unmap time is also redundant for udmabuf: > begin_cpu_udmabuf() and end_cpu_udmabuf() already perform explicit > cache synchronization via dma_sync_sgtable_for_cpu/device() when CPU > access is requested through the dma-buf interface. This, however, does not apply to the first time begin_cpu_udmabuf() is called on an udmabuf, in which case the implementation previously relied on get_sg_table() to perform the cache synchronisation. Ensure to call dma_sync_sgtable_for_cpu() in that case as well. Fixes: 504e2b4ab97a ("dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning") Signed-off-by: Robert Mader Reviewed-by: Mikhail Gavrilov Signed-off-by: Vivek Kasireddy Link: https://patch.msgid.link/20260627105725.9083-1-robert.mader@collabora.com Signed-off-by: Greg Kroah-Hartman

dma-buf/drivers: make reserving a shared slot mandatory v4

2026-08-23T12:17:25+00:00

[ Upstream commit c8d4c18bfbc4ab467188dbe45cc8155759f49d9e ] Audit all the users of dma_resv_add_excl_fence() and make sure they reserve a shared slot also when only trying to add an exclusive fence. This is the next step towards handling the exclusive fence like a shared one. v2: fix missed case in amdgpu v3: and two more radeon, rename function v4: add one more case to TTM, fix i915 after rebase Signed-off-by: Christian König Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220406075132.3263-2-christian.koenig@amd.com Stable-dep-of: a48bbcc7ac73 ("drm/virtio: use uninterruptible resv lock for plane updates") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning

2026-08-23T12:17:17+00:00

[ Upstream commit 504e2b4ab97a51d56d966cd36d0997ad30b65b2d ] When CONFIG_DMA_API_DEBUG_SG is enabled, importing a udmabuf into a DRM driver (e.g. amdgpu for video playback in GNOME Videos / Showtime) triggers a spurious warning: DMA-API: amdgpu 0000:03:00.0: cacheline tracking EEXIST, \ overlapping mappings aren't supported WARNING: kernel/dma/debug.c:619 at add_dma_entry+0x473/0x5f0 The call chain is: amdgpu_cs_ioctl -> amdgpu_ttm_backend_bind -> dma_buf_map_attachment -> [udmabuf] map_udmabuf -> get_sg_table -> dma_map_sgtable(dev, sg, direction, 0) // attrs=0 -> debug_dma_map_sg -> add_dma_entry -> EEXIST This happens because udmabuf builds a per-page scatter-gather list via sg_set_folio(). When begin_cpu_udmabuf() has already created an sg table mapped for the misc device, and an importer such as amdgpu maps the same pages for its own device via map_udmabuf(), the DMA debug infrastructure sees two active mappings whose physical addresses share cacheline boundaries and warns about the overlap. The DMA_ATTR_SKIP_CPU_SYNC flag suppresses this check in add_dma_entry() because it signals that no CPU cache maintenance is performed at map/unmap time, making the cacheline overlap harmless. All other major dma-buf exporters already pass this flag: - drm_gem_map_dma_buf() passes DMA_ATTR_SKIP_CPU_SYNC - amdgpu_dma_buf_map() passes DMA_ATTR_SKIP_CPU_SYNC The CPU sync at map/unmap time is also redundant for udmabuf: begin_cpu_udmabuf() and end_cpu_udmabuf() already perform explicit cache synchronization via dma_sync_sgtable_for_cpu/device() when CPU access is requested through the dma-buf interface. Pass DMA_ATTR_SKIP_CPU_SYNC to dma_map_sgtable() and dma_unmap_sgtable() in udmabuf to suppress the spurious warning and skip the redundant sync. Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks") Cc: stable@vger.kernel.org Signed-off-by: Mikhail Gavrilov Acked-by: Vivek Kasireddy Signed-off-by: Vivek Kasireddy Link: https://patch.msgid.link/20260331061657.79983-1-mikhail.v.gavrilov@gmail.com Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

udmabuf: Do not create malformed scatterlists

2026-08-23T12:17:17+00:00

[ Upstream commit 5bf888673e0dda5a53220fa0c4956271a46c353c ] Using a sg_set_folio() loop for every 4K results in a malformed scatterlist because sg_set_folio() has an issue with offsets > PAGE_SIZE and because scatterlist expects the creator to build a list which consolidates any physical contiguity. sg_alloc_table_from_pages() creates a valid scatterlist directly from a struct page array, so go back to that. Remove the offsets allocation and just store an array of tail pages as it did before the below commit. Everything wants that anyhow. Fixes: 0c8b91ef5100 ("udmabuf: add back support for mapping hugetlb pages") Reported-by: Julian Orth Closes: https://lore.kernel.org/all/20260308-scatterlist-v1-1-39c4566b0bba@gmail.com/ Signed-off-by: Jason Gunthorpe Reviewed-by: Vivek Kasireddy Signed-off-by: Vivek Kasireddy Link: https://patch.msgid.link/0-v1-42779f29381a+4b9-udmabuf_sg_jgg@nvidia.com Stable-dep-of: 504e2b4ab97a ("dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

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