kernel/linux.git/include/linux/dma-fence.h, branch linux-7.1.y

dma-fence: correct kernel-doc function parameter @flags

2026-04-08T13:27:47+00:00

'make htmldocs' complains that dma_fence_unlock_irqrestore() is missing a description of its @flags parameter. The description is there but it is missing a ':' sign. Add that and correct the possessive form of "its". WARNING: ../include/linux/dma-fence.h:414 function parameter 'flags' not described in 'dma_fence_unlock_irqrestore' Fixes: 3e5067931b5d ("dma-buf: abstract fence locking v2") Signed-off-by: Randy Dunlap Link: https://lore.kernel.org/r/20260407043649.2015894-1-rdunlap@infradead.org Reviewed-by: Christian König Signed-off-by: Christian König

dma-buf: inline spinlock for fence protection v5

2026-02-23T15:14:19+00:00

Implement per-fence spinlocks, allowing implementations to not give an external spinlock to protect the fence internal state. Instead a spinlock embedded into the fence structure itself is used in this case. Shared spinlocks have the problem that implementations need to guarantee that the lock lives at least as long all fences referencing them. Using a per-fence spinlock allows completely decoupling spinlock producer and consumer life times, simplifying the handling in most use cases. v2: improve naming, coverage and function documentation v3: fix one additional locking in the selftests v4: separate out some changes to make the patch smaller, fix one amdgpu crash found by CI systems v5: improve comments Signed-off-by: Christian König Reviewed-by: Boris Brezillon Link: https://lore.kernel.org/r/20260219160822.1529-5-christian.koenig@amd.com

dma-buf: abstract fence locking v2

2026-02-23T15:14:19+00:00

Add dma_fence_lock_irqsafe() and dma_fence_unlock_irqrestore() wrappers and mechanically apply them everywhere. Just a pre-requisite cleanup for a follow up patch. v2: add some missing i915 bits, add abstraction for lockdep assertion as well v3: one more suggestion by Tvrtko Signed-off-by: Christian König Reviewed-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20260219160822.1529-4-christian.koenig@amd.com

dma-buf: detach fence ops on signal v3

2026-02-23T15:14:02+00:00

When neither a release nor a wait backend ops is specified it is possible to let the dma_fence live on independently of the module who issued it. This makes it possible to unload drivers and only wait for all their fences to signal. v2: fix typo in comment v3: fix sparse rcu warnings Signed-off-by: Christian König Reviewed-by: Tvrtko Ursulin Reviewed-by: Philipp Stanner Reviewed-by: Boris Brezillon Link: https://lore.kernel.org/r/20260219160822.1529-3-christian.koenig@amd.com

dma-buf: protected fence ops by RCU v8

2026-02-23T15:09:56+00:00

The fence ops of a dma_fence currently need to life as long as the dma_fence is alive. This means that the module which originally issued a dma_fence can't unload unless all fences are freed up. As first step to solve this issue protect the fence ops by RCU. While it is counter intuitive to protect a constant function pointer table by RCU it allows modules to wait for an RCU grace period before they unload, to make sure that nobody is executing their functions any more. This patch has not much functional change, but only adds the RCU handling for the static checker to test. v2: make one the now duplicated lockdep warnings a comment instead. v3: Add more documentation to ->wait and ->release callback. v4: fix typo in documentation v5: rebased on drm-tip v6: improve code comments v7: improve commit message and code comments v8: fix sparse rcu warnings Signed-off-by: Christian König Reviewed-by: Tvrtko Ursulin Reviewed-by: Boris Brezillon Link: https://lore.kernel.org/r/20260219160822.1529-2-christian.koenig@amd.com

dma-buf: add dma_fence_was_initialized function v2

2026-02-05T10:02:56+00:00

Some driver use fence->ops to test if a fence was initialized or not. The problem is that this utilizes internal behavior of the dma_fence implementation. So better abstract that into a function. v2: use a flag instead of testing fence->ops, rename the function, move to the beginning of the patch set. Signed-off-by: Christian König Reviewed-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20260120105655.7134-2-christian.koenig@amd.com

dma-buf/dma-fence: Remove return code of signaling-functions

2025-12-04T14:03:40+00:00

All functions used for signaling a fence return an error code whose sole purpose is to tell whether a fence was already signaled. This is racy and has been used by almost no party in the kernel, and the few users have been removed in preceding cleanup commits. Turn all signaling-functions into void-functions. Suggested-by: Christian König Reviewed-by: Christian König Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20251201105011.19386-9-phasta@kernel.org

dma-buf/dma-fence: Add dma_fence_check_and_signal()

2025-12-04T14:03:40+00:00

The overwhelming majority of users of dma_fence signaling functions don't care about whether the fence had already been signaled by someone else. Therefore, the return code shall be removed from those functions. For the few users who rely on the check, a new, specialized function shall be provided. Add dma_fence_check_and_signal(), which signals a fence if it had not yet been signaled, and informs the user about that. Add a counter part, dma_fence_check_and_signal_locked(), which doesn't take the spinlock. Reviewed-by: Christian König Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20251201105011.19386-4-phasta@kernel.org

dma-buf/dma-fence: Add dma_fence_test_signaled_flag()

2025-12-04T14:03:39+00:00

The dma_fence framework checks at many places whether the signaled flag of a fence is already set. The code can be simplified and made more readable by providing a helper function for that. Add dma_fence_test_signaled_flag(), which only checks whether a fence is signaled. Use it internally. Suggested-by: Tvrtko Ursulin Reviewed-by: Christian König Signed-off-by: Philipp Stanner Link: https://patch.msgid.link/20251201105011.19386-3-phasta@kernel.org

dma-fence: Add safe access helpers and document the rules

2025-06-13T07:26:49+00:00

Dma-fence objects currently suffer from a potential use after free problem where fences exported to userspace and other drivers can outlive the exporting driver, or the associated data structures. The discussion on how to address this concluded that adding reference counting to all the involved objects is not desirable, since it would need to be very wide reaching and could cause unloadable drivers if another entity would be holding onto a signaled fence reference potentially indefinitely. This patch enables the safe access by introducing and documenting a contract between fence exporters and users. It documents a set of contraints and adds helpers which a) drivers with potential to suffer from the use after free must use and b) users of the dma-fence API must use as well. Premise of the design has multiple sides: 1. Drivers (fence exporters) MUST ensure a RCU grace period between signalling a fence and freeing the driver private data associated with it. The grace period does not have to follow the signalling immediately but HAS to happen before data is freed. 2. Users of the dma-fence API marked with such requirement MUST contain the complete access to the data within a single code block guarded by rcu_read_lock() and rcu_read_unlock(). The combination of the two ensures that whoever sees the DMA_FENCE_FLAG_SIGNALED_BIT not set is guaranteed to have access to a valid fence->lock and valid data potentially accessed by the fence->ops virtual functions, until the call to rcu_read_unlock(). 3. Module unload (fence->ops) disappearing is for now explicitly not handled. That would required a more complex protection, possibly needing SRCU instead of RCU to handle callers such as dma_fence_release() and dma_fence_wait_timeout(), where race between dma_fence_enable_sw_signaling, signalling, and dereference of fence->ops->wait() would need a sleeping SRCU context. Signed-off-by: Tvrtko Ursulin Reviewed-by: Christian König Signed-off-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20250610164226.10817-4-tvrtko.ursulin@igalia.com