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

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

dma-fence: Add helpers for accessing driver and timeline name

2025-06-03T16:38:22+00:00

Add some helpers in order to enable preventing dma-fence users accessing the implementation details directly and make the implementation itself use them. This will also enable later adding some asserts to a consolidated location. Signed-off-by: Tvrtko Ursulin Reviewed-by: Christian König Signed-off-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20250515095004.28318-4-tvrtko.ursulin@igalia.com

dma-fence: Use a flag for 64-bit seqnos

2025-06-03T16:38:04+00:00

With the goal of reducing the need for drivers to touch (and dereference) fence->ops, we move the 64-bit seqnos flag from struct dma_fence_ops to the fence->flags. Drivers which were setting this flag are changed to use new dma_fence_init64() instead of dma_fence_init(). v2: * Streamlined init and added kerneldoc. * Rebase for amdgpu userq which landed since. Signed-off-by: Tvrtko Ursulin Reviewed-by: Christian König # v1 Signed-off-by: Tvrtko Ursulin Link: https://lore.kernel.org/r/20250515095004.28318-3-tvrtko.ursulin@igalia.com

dma-buf: Add forward declaration of struct seq_file in dma-fence.h

2025-06-02T12:31:51+00:00

Add forward declaration of struct seq_file before using it in function prototype. Signed-off-by: Herbert Xu Reviewed-by: Christian König Signed-off-by: Christian König Link: https://lore.kernel.org/r/aDlu5TGyA1WuMsvw@gondor.apana.org.au

dma-fence: Change signature of __dma_fence_is_later

2025-05-15T13:05:29+00:00

With the goal of reducing the need for drivers to touch (and dereference) fence->ops, we change the prototype of __dma_fence_is_later() to take fence instead of fence->ops. Signed-off-by: Tvrtko Ursulin Reviewed-by: Christian König Link: https://lore.kernel.org/r/20250515095004.28318-2-tvrtko.ursulin@igalia.com Signed-off-by: Christian König

dma-buf/dma-fence: remove unnecessary callbacks

2025-03-06T14:20:53+00:00

The fence_value_str and timeline_value_str callbacks were just an unnecessary abstraction in the SW sync implementation. The only caller of those callbacks already knew that the fence in questions is a timeline_fence. So print the values directly instead of using a redirection. Additional to that remove the implementations from virtgpu and vgem. As far as I can see those were never used in the first place. Signed-off-by: Christian König Reviewed-by: Simona Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20250211163109.12200-3-christian.koenig@amd.com

dma-buf: fix incorrect dma-fence documentation v2

2025-03-06T14:20:43+00:00

There isn't much worse than documentation giving an incorrect advise. Grabbing a spinlock while interrupts are disabled usually means that you must also disable interrupts for all other uses of this spinlock. Otherwise really hard to debug issues can occur. So fix that invalid documentation. v2: use Dmitry's suggestion on the documentation Signed-off-by: Christian König Reviewed-by: Simona Vetter (v1) Link: https://patchwork.freedesktop.org/patch/msgid/20250211163109.12200-2-christian.koenig@amd.com