STRUCT DMA_FENCE_OPS(9)

📦 version 7.3.1, in nixpkgs unstable

okay so this is struct dma_fence_ops(9) from the Kernel API Manual — literally the operations you implement for a fence, and we're gonna go through every single callback, no skips bestie 💅✨

💖 NAME 💖

struct dma_fence_ops — the operations implemented for a fence 🎀 no cap, this is the whole vibe of the page.

✨ SYNOPSIS ✨

here's the struct in all its glory:

struct dma_fence_ops {
    const char * (*get_driver_name)(struct dma_fence *fence);
    const char * (*get_timeline_name)(struct dma_fence *fence);
    bool (*enable_signaling)(struct dma_fence *fence);
    bool (*signaled)(struct dma_fence *fence);
    signed long (*wait)(struct dma_fence *fence, bool intr, signed long
timeout);
    void (*release)(struct dma_fence *fence);
    void (*set_deadline)(struct dma_fence *fence, ktime_t deadline);
};

🦋 Members 🦋

get_driver_name

Returns the driver name. This is a callback so drivers can compute the name at runtime, without having it to store permanently for each fence, or build a cache of some sort 🫶

The returned string is RCU protected, and it can be freed after the fence signaled and an RCU grace period passed ✨

This callback is mandatory.

get_timeline_name

Return the name of the context this fence belongs to. This is a callback so drivers can compute the name at runtime, without having it to store permanently for each fence, or build a cache of some sort 🌸

The returned string is RCU protected, and it can be freed after the fence signaled and an RCU grace period passed ✨

This callback is mandatory.

enable_signaling

Enable software signaling of fence 💫

For fence implementations that have the capability for hw->hw signaling, they can implement this op to enable the necessary interrupts, or insert commands into cmdstream, etc, to avoid these costly operations for the common case where only hw->hw synchronization is required. This is called in the first dma_fence_wait or dma_fence_add_callback path to let the fence implementation know that there is another driver waiting on the signal (ie. hw->sw case) 🔥

This is called with irq's disabled, so only spinlocks which disable IRQ's can be used in the code outside of this callback.

A return value of false indicates the fence already passed, or some failure occurred that made it impossible to enable signaling. true indicates successful enabling 👑

dma_fence.error may be set in enable_signaling, but only when false is returned.

Since many implementations can call dma_fence_signal even before enable_signaling has been called, there's a race window where dma_fence_signal might result in the final fence reference being released and its memory freed 😭 To avoid this, implementations of this callback should grab their own reference using dma_fence_get, to be released when the fence is signalled (through e.g. the interrupt handler).

This callback is optional. If this callback is not present, then the driver must always have signaling enabled.

signaled

Peek whether the fence is signaled, as a fastpath optimization for e.g. dma_fence_wait or dma_fence_add_callback. Note that this callback does not need to make any guarantees beyond that a fence once indicates as signalled must always return true from this callback 💖 This callback may return false even if the fence has completed already; in this case information hasn't propogated throug the system yet. See also dma_fence_is_signaled 👀

May set dma_fence.error if returning true.

This callback is optional.

wait

Custom wait implementation, defaults to dma_fence_default_wait if not set.

Deprecated and should not be used by new implementations. Only used by existing implementations which need special handling for their hardware reset procedure ⚠️

Must return -ERESTARTSYS if the wait is intr = true and the wait was interrupted, and remaining jiffies if fence has signaled, or 0 if wait timed out. Can also return other error values on custom implementations, which should be treated as if the fence is signaled. For example a hardware lockup could be reported like that 💀

Implementing this callback prevents the fence from detaching after signaling and so it is necessary for the module providing the dma_fence_ops to stay loaded as long as the dma_fence exists.

release

Called on destruction of fence to release additional resources. Can be called from irq context. This callback is optional. If it is NULL, then dma_fence_free is instead called as the default implementation 🎀

Implementing this callback prevents the fence from detaching after signaling and so it is necessary for the module providing the dma_fence_ops to stay loaded as long as the dma_fence exists.

If the callback is implemented the memory backing the dma_fence object must be freed RCU safe.

set_deadline

Callback to allow a fence waiter to inform the fence signaler of an upcoming deadline, such as vblank, by which point the waiter would prefer the fence to be signaled by. This is intended to give feedback to the fence signaler to aid in power management decisions, such as boosting GPU frequency ⚡

This is called without dma_fence.lock held, it can be called multiple times and from any context. Locking is up to the callee if it has some state to manage. If multiple deadlines are set, the expectation is to track the soonest one. If the deadline is before the current time, it should be interpreted as an immediate deadline ⏰

This callback is optional.

🌈 SEE ALSO 🌈

Kernel file: ./include/linux/dma-fence.h

and then the whole squad, fr fr:

mwah 💋 page source/version: ./include/linux; date: October 2026 — now go make those fences iconic, bestie 🫶✨

📦 where this page comes from