rust / dma_buf: Add abstractions for dma_fence

C's dma_fence's are synchronisation primitives that will be needed by all Rust GPU drivers.

The dma_fence framework sets a number of rules, notably:
- fences must only be signalled once
- all fences must be signalled at some point
- fence error codes must only be set before signalling
- every pointer to a fence must be backed by a reference

All those rules are being addressed by these abstractions.

To cleanly decouple fence issuers and consumers, two types are provided:
- DriverFence: the only fence type that can be signalled and that carries driver-specific data.
- Fence: the fence type to be shared with other drivers and / or userspace. The only type callbacks can be registered on. Cannot be signalled.

Hereby, a Fence lives in the same chunk of memory as a DriverFence. Both share the refcount of the underlying C dma_fence. Since this implementation does not provide a custom dma_fence_backend_ops.release() function, the memory is freed by the dma_fence backend once the refcount drops to 0.

To create a DriverFence, the user must first allocate a DriverFenceAllocation, so that the creation of the DriverFence later on can always succeed. Otherwise, deadlocks could occur if fences need to be created in a GPU job submission path.

Synchronization is ensured by the dma_fence backend.

All DriverFence's created through this abstraction must be signalled by the creator with an error code. In case a DriverFence drops without being signalled beforehand, it is signalled with -ECANCELLED as its error and a warning is printed. This allows the Rust abstraction to very cleanly decouple fence issuer and consumer by relying on the decoupling mechanisms in the C backend, which ensures through RCU and the 'signalled' fence-flag that dma_fence_backend_ops functions cannot access the potentially unloaded driver code anymore.

Signalling fences on drop thus grants many advantages. Not signalling fences on drop would risk deadlock and does not grant real advantages:
By definition only the drivers can ensure that a fence always represents the hardware's state correctly.

This implementation models a DmaFenceCtx (fence context) object on which fences are to be created, thereby ensuring correct sequence numbering according to the timeline.

dma_fence supports a variety of callbacks. The mandatory callbacks (get_timeline_name() and get_driver_name()) are implemented in this patch. For convenience, they store those name parameters in the fence context, saving the driver from implementing these two callbacks.

Support for other callbacks (like for hardware signalling) is prepared for through the fact that both DriverFence and Fence live in the same allocation, allowing for usage of container_of from the callback to access the driver-specific data.

Synchronization for backend_ops callbacks is ensured by only running the Rust deconstructor delayed with call_rcu(), which prevents UAF-bugs should a DriverFence drop while a Fence callback is currently operating on the associated driver data.

Add abstractions for dma_fence in Rust.

Signed-off-by Philipp Stanner <[email protected]>

---
 rust/bindings/bindings_helper.h  |   1 +
 rust/helpers/dma_fence.c         |  48 ++
 rust/helpers/helpers.c           |   1 +
 rust/kernel/dma_buf/dma_fence.rs | 884 +++++++++++++++++++++++++++++++
 rust/kernel/dma_buf/mod.rs       |  14 +
 rust/kernel/lib.rs               |   1 +
 6 files changed, 949 insertions(+)
 create mode 100644 rust/helpers/dma_fence.c
 create mode 100644 rust/kernel/dma_buf/dma_fence.rs
 create mode 100644 rust/kernel/dma_buf/mod.rs

rust/bindings/bindings_helper.h +1 -0

index 446dbeaf0866..814d7740e686 100644
@@ -52,6 +52,7 @@
 #include <linux/debugfs.h>
 #include <linux/device/faux.h>
 #include <linux/dma-direction.h>
+#include <linux/dma-fence.h>
 #include <linux/dma-mapping.h>
 #include <linux/dma-resv.h>
 #include <linux/errname.h>

rust/helpers/dma_fence.c new file +13 -0

new file mode 100644
index 000000000000..0e08411098fa
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include <linux/dma-fence.h>
+
+__rust_helper void rust_helper_dma_fence_get(struct dma_fence *f)
+{
+	dma_fence_get(f);
+}
+
+__rust_helper void rust_helper_dma_fence_put(struct dma_fence *f)
+{
+	dma_fence_put(f);
+}

rust/helpers/dma_fence.c new file +5 -0

+
+    /// Create a [`FenceCtx`] from an associated [`bindings::dma_fence`].
+    ///
+    /// # Safety
+    ///

rust/helpers/dma_fence.c new file +17 -0

+
+        // SAFETY: Safe because of the safety comment directly above.
+        let fence_data = unsafe { &*fence_data_ptr };
+
+        &fence_data.fctx
+    }
+}
+
+/// Error type for fence callback registration.
+///
+/// Generic over `T` so that `AlreadySignaled` can return the callback to the
+/// caller, allowing it to reclaim any resources owned by the callback (e.g.,
+/// a fence handle that needs to be signaled).
+#[derive(Debug)]
+pub enum CallbackError<T = ()> {
+    /// The fence was already signaled. The callback is returned so the caller
+    /// can extract owned resources without losing them.

rust/helpers/dma_fence.c new file +22 -0

+        //
+        // Without this, Drop can race with a concurrent signal:
+        //   CPU0 (signal, lock held): take() -> signaled(fence_ref) (in progress)
+        //   CPU1 (drop): sees is_some()==false -> skips lock -> frees struct
+        //   CPU0: accesses fence_ref -> use-after-free
+        //
+        // When the callback has already fired, the signal path detached the
+        // list node via INIT_LIST_HEAD, so dma_fence_remove_callback just sees
+        // an empty node and returns false — the lock acquisition is the only
+        // thing that matters.
+        //
+        // SAFETY: The fence pointer is valid and the cb was initialized by
+        // dma_fence_add_callback during construction.
+        unsafe {
+            bindings::dma_fence_remove_callback(self.fence.as_raw(), self.cb.get());
+        }
+    }
+}
+
+// SAFETY: FenceCbRegistration can be sent between threads
+unsafe impl<T: FenceCb> Send for FenceCbRegistration<T> {}
+

rust/helpers/dma_fence.c new file +25 -0

+
+// SAFETY: Fences are literally designed to be shared between threads.
+unsafe impl Send for Fence {}
+// SAFETY: Fences are literally designed to be shared between threads.
+unsafe impl Sync for Fence {}
+
+impl Fence {
+    /// Check whether the fence was signalled at the moment of the function call.
+    ///
+    /// Note that this can return `true` for a [`Fence`] whose [`DriverFence`]
+    /// has not yet been dropped. The reason is that the fence ops callbacks can
+    /// cause the fence to get signaled by the C backend.
+    pub fn is_signaled(&self) -> bool {
+        let fence = self.as_raw();
+        let mut fence_flags: usize = 0;
+        let flag_ptr = &raw mut fence_flags;
+
+        // We shouuld not use `dma_fence_is_signaled_locked()` here, because
+        // according to the C backend's recommendations, that function is problematic
+        // and we should avoid calling that function with a lock held.
+
+        // SAFETY: `self` is valid by definition. We take the spinlock above.
+        let ret = unsafe { bindings::dma_fence_is_signaled(fence) };
+
+        // To guarantee that an API caller can 100% rely on the signalling being

rust/helpers/dma_fence.c new file +5 -0

+    unsafe { bindings::dma_fence_put(fence) };
+
+    // The actual memory the data associated with a `DriverFence` lives in
+    // gets freed by the C dma_fence backend once the fence's refcount reaches 0.
+}

rust/kernel/dma_buf/mod.rs new file +14 -0

new file mode 100644
index 000000000000..fb353ce042ce
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+
+//! DMA-buf subsystem abstractions.
+
+pub mod dma_fence;
+
+pub use self::dma_fence::{
+    DriverFence,
+    Fence,
+    FenceCb,
+    FenceCbRegistration,
+    FenceCtx,
+    FenceCtxOps, //
+};

rust/kernel/lib.rs +1 -0

index b72b2fbe046d..a05ccaa7598c 100644
@@ -63,6 +63,7 @@
 pub mod device_id;
 pub mod devres;
 pub mod dma;
+pub mod dma_buf;
 pub mod driver;
 #[cfg(CONFIG_DRM = "y")]
 pub mod drm;

Signature · 1 line

2.54.0

On Tue, 16 Jun 2026 10:28:17 +0200

Quoted 3 lines

+
+        // DriverFenceData is repr(C) and a Fence is its first member. +        let fence_data_ptr = fence_ptr as *mut DriverFenceData<T>;

Either the field ordering on the type or this code is wrong because the first member of DriverFenceData is rcu_head.

Quoted 2 lines

+}

I am unsure whether it is safe to cast the pointer in Fence::from_raw without Fence being #[repr(transparent)] as the layout compatibility is not guaranteed explicitly.

Quoted 7 lines · Onur Özkan

On Tue, 16 Jun 2026 10:28:17 +0200

Quoted 3 lines

+
+        // DriverFenceData is repr(C) and a Fence is its first member. +        let fence_data_ptr = fence_ptr as *mut DriverFenceData<T>;

Either the field ordering on the type or this code is wrong because the first member of DriverFenceData is rcu_head.

Yeah, that's a bug introduced in this revision. Thx for pointing it out. Already fixed it downstream.

I'm just wondering why my test did not blow up.

Quoted 6 lines

Quoted 2 lines

+}

I am unsure whether it is safe to cast the pointer in Fence::from_raw without Fence being #[repr(transparent)] as the layout compatibility is not guaranteed explicitly.

Shouldn't #[repr(C)] do that trick, too? Do you need both?

Who can answer that?

P.

repr(C) only makes sense when the type have multiple fields.

Quoted 1 line · Onur Özkan

repr(C) only makes sense when the type have multiple fields.

I don't think that's universally true. repr(transparent) guarantees the layout and ABI match the inner field. The wrapper is passed through calls exactly as the field would be. repr(C) guarantees C-compatible layout and makes the type follow the platform's C ABI for passing an aggregate, which isn't always how the bare field is passed.

Quoted 7 lines · Onur Özkan

On Tue, 16 Jun 2026 10:28:17 +0200

Quoted 3 lines

+
+        // DriverFenceData is repr(C) and a Fence is its first member. +        let fence_data_ptr = fence_ptr as *mut DriverFenceData<T>;

Either the field ordering on the type or this code is wrong because the first member of DriverFenceData is rcu_head.

Yeah, that's a bug introduced in this revision. Thx for pointing it out. Already fixed it downstream.

I'm just wondering why my test did not blow up.

Quoted 3 lines

Quoted 2 lines

+}

Quoted 3 lines

I am unsure whether it is safe to cast the pointer in Fence::from_raw without Fence being #[repr(transparent)] as the layout compatibility is not guaranteed explicitly.

Shouldn't #[repr(C)] do that trick, too? Do you need both?

Who can answer that?

Add abstractions for dma_fence in Rust.

Signed-off-by Philipp Stanner <[email protected]>

---
 rust/bindings/bindings_helper.h  |   1 + rust/helpers/dma_fence.c         |  48 ++ rust/helpers/helpers.c           |   1 + rust/kernel/dma_buf/dma_fence.rs | 884 +++++++++++++++++++++++++++++++ rust/kernel/dma_buf/mod.rs       |  14 +
 rust/kernel/lib.rs               |   1 +

 6 files changed, 949 insertions(+)

 create mode 100644 rust/helpers/dma_fence.c create mode 100644 rust/kernel/dma_buf/dma_fence.rs create mode 100644 rust/kernel/dma_buf/mod.rs

rust/kernel/dma_buf/dma_fence.rs new file +9 -0

+
+/// The receiving counterpart of a [`DriverFence`], designed to register callbacks
+/// on, check the signalled state etc. A [`Fence`] cannot be signalled.
+/// A [`Fence`] is always refcounted.
+pub struct Fence {
+    /// The actual dma_fence passed to C.
+    inner: Opaque<bindings::dma_fence>,
+}
+

rust/kernel/dma_buf/dma_fence.rs new file +18 -0

+
+#[repr(C)] // Necessary to guarantee that `inner` always comes first so that we can cast.
+#[pin_data]
+struct DriverFenceData<T: Send + Sync + FenceCtxOps> {
+    /// Callback head for dropping this in a deferred manner through RCU.
+    rcu_head: bindings::callback_head,
+    #[pin]
+    /// The inner fence.
+    inner: Fence,
+    /// Pointer to access the FenceCtx. Useful for obtaining name parameters.
+    fctx: Arc<FenceCtx<T>>,
+    /// The API user's data. This must either not need drop, or must delay its
+    /// drop by a grace period. It is essential that the data only performs
+    /// operations legal in atomic context in its [`Drop`] implementation.
+    #[pin]
+    data: T::FenceDataType,
+}
+

rust/kernel/dma_buf/dma_fence.rs new file +8 -0

+pub struct DriverFence<T: Send + Sync + FenceCtxOps> {
+    /// The actual content of the fence. Lives in a raw pointer so that its
+    /// memory can be managed independently. Valid until both the [`DriverFence`]
+    /// and all associated [`Fence`]s have disappeared.
+    data: NonNull<DriverFenceData<T>>,
+}
+
+

}

rust/kernel/dma_buf/dma_fence.rs new file +69 -0

+
+impl<T: Send + Sync + FenceCtxOps> Drop for DriverFence<T> {
+    fn drop(&mut self) {
+        let fence = self.as_raw();
+        let mut fence_flags: usize = 0;
+        let flag_ptr = &raw mut fence_flags;
+
+        // SAFETY: `fence` is valid until the `call_rcu()` below. `flag_ptr` is
+        // merely a pointer to an integer, which lives as long as this function.
+        unsafe { bindings::dma_fence_lock_irqsave(fence, flag_ptr) };
+
+        // Use dma_fence_test_signaled_flag() instead of dma_fence_is_signaled_locked()
+        // because the C backend wants to get rid of the latter.
+
+        // SAFETY: `fence` is valid until the `call_rcu()` below.
+        let signaled: bool = unsafe { bindings::dma_fence_test_signaled_flag(fence) };
+        if warn_on!(!signaled) {
+            // SAFETY: `fence` is valid until the `call_rcu()` below. The fence
+            // must not have been signaled yet, which we check directly above.
+            unsafe { bindings::dma_fence_set_error(fence, ECANCELED.to_errno()) };
+            // SAFETY: `fence` is valid until the `call_rcu()` below. The lock must
+            // be held, which we acquired above.
+            unsafe { bindings::dma_fence_signal_locked(fence) };
+        }
+        // SAFETY: `fence` is valid until the `call_rcu()` below. `flag_ptr` is
+        // merely a pointer to an integer, which lives as long as this function.
+        // The lock must be held, which we acquired above.
+        unsafe { bindings::dma_fence_unlock_irqrestore(fence, flag_ptr) };
+
+        // SAFETY: Valid because `self` is valid.
+        let rcu_head_ptr = unsafe { &raw mut (*self.data.as_ptr()).rcu_head };
+
+        // `DriverFenceData` but could be accessed through some dma_fence callbacks
+        // right now. Access is being revoked in principle above by signalling
+        // the fence, but since the C backend does not guarantee perfect full
+        // synchronization, we have to wait for one grace period to ensure that
+        // all accessors of `DriverFenceData` (through the dma_fence_ops accessible
+        // through a `Fence`) are gone.
+
+        // SAFETY: `call_rcu()` is always safe to be called. `rcu_head_ptr` was created
+        // validly above. The module must perform a `synchronize_rcu()` or
+        // `rcu_barrier()` call to guard against module unload.
+        unsafe { bindings::call_rcu(rcu_head_ptr, Some(drop_driver_fence_data::<T>)) };
+    }
+}
+
+// TODO:
+// The entire call_rcu() mechanism in the drop above and the code below would be
+// unnecessary if C's dma_fence_signal() could be reworked in a way that after it
+// ran, the caller knows that no fence_ops callbacks can be running anymore.
+// In other words, if the dma_fence backend would use its spinlock for full
+// synchronization.
+//
+// Then we could move the drop_in_place() and dma_fence_put() upwards into the
+// drop() implementation and call it a day.
+
+/// Finally really drop this `DriverFence<T>`
+///
+/// # Safety
+///
+/// `head` references the `rcu_head` field of an `DriverFenceData<T>`. All
+/// accessors to that `DriverFenceData<T>` must be gone by now. This must be
+/// ensured by signalling the associated `DriverFence<T>` and then waiting
+/// for a grace period until calling this function here.
+unsafe extern "C" fn drop_driver_fence_data<T: Send + Sync + FenceCtxOps>(
+    head: *mut bindings::callback_head,
+) {
+    // SAFETY: Caller provides a pointer to the `rcu_head` field of a `DriverFenceData<C>`.
+    let fence_data = unsafe { container_of!(head, DriverFenceData<T>, rcu_head) };

Changes since v1:

Quoted 1 line · Philipp Stanner

Changes since v1:

It seems that some of the comments from v1 [1][2] are not addressed, did you forget them?

In particular the pin_init_from_closure() looks unnecessary and can probably replaced with something like (untested):

	let mut callback = Some(callback);
	
	try_pin_init!(Self {
	    cb <- Opaque::try_ffi_init(|ptr| {
	        // SAFETY: `fence.inner.get()` is a valid, initialized `struct dma_fence`. `ptr`
	        // points to the `struct dma_fence_cb` field within the pinned allocation, so it
	        // remains valid until `dma_fence_remove_callback()` in `PinnedDrop` or until the
	        // callback fires.
	        let ret = unsafe {
	            to_result(bindings::dma_fence_add_callback(
	                fence.inner.get(),
	                ptr,
	                Some(Self::dma_fence_callback),
	            ))
	        };
	        match ret {
	            Ok(()) => Ok(()),
	            Err(e) => {
	                let cb_back = callback.take().expect("success path did not run");
	                if e == ENOENT {
	                    Err(CallbackError::AlreadySignaled(cb_back))
	                } else {
	                    Err(CallbackError::Other(e))
	                }
	            }
	        }
	    }),
	    callback: callback.take().expect("error path did not run"),
	    fence: ARef::from(fence),
	}? CallbackError<T>)

Please also see my previous comments regarding DriverFenceBorrow, it still seems to miss the lifetime and it should probably use ManuallyDrop<DriverFence>.

It also seems the patch series was created without --base, what's the base revision?

[1] https://lore.kernel.org/all/[email protected]/
[2] https://lore.kernel.org/all/[email protected]/