FENCE CROSS-DRIVER CONTRACT(9)

fence cross-driver contract(9) 🎀

okay so this is from the Kernel API Manual, and it’s the whole dma_fence cross-driver contract situation, bestie 💅. Since dma_fence provides a cross-driver contract, literally every driver has to follow the same rules, no cap:

• Fences must complete in a reasonable time. Fences which represent kernels and shaders submitted by userspace could run forever, so they must be backed up by timeout and gpu hang recovery code. Minimally that code must prevent further command submission and force complete all in-flight fences, e.g. when the driver or hardware do not support gpu reset, or if the gpu reset failed for some reason. Ideally the driver supports gpu recovery which only affects the offending userspace context, and no other userspace submissions. ✨
• Drivers may have different ideas of what completion within a reasonable time means. Some hang recovery code uses a fixed timeout, others a mix between observing forward progress and increasingly strict timeouts. Drivers should not try to second guess timeout handling of fences from other drivers. 🙅‍♀️
• Deadlock prevention era. To ensure there’s no deadlocks of dma_fence_wait against other locks, drivers should annotate all code required to reach dma_fence_signal, which completes the fences, with dma_fence_begin_signalling and dma_fence_end_signalling. 🔒
• Drivers are allowed to call dma_fence_wait while holding dma_resv_lock. This means any code required for fence completion cannot acquire a dma_resv lock. Note that this also pulls in the entire established locking hierarchy around dma_resv_lock and dma_resv_unlock. 😮‍💨
• Drivers are allowed to call dma_fence_wait from their shrinker callbacks. This means any code required for fence completion cannot allocate memory with GFP_KERNEL. 🧠
• Drivers are allowed to call dma_fence_wait from their mmu_notifier respectively mmu_interval_notifier callbacks. This means any code required for fence completion cannot allocate memory with GFP_NOFS or GFP_NOIO. Only GFP_ATOMIC is permissible, which might fail. ⚠️

Note that only GPU drivers have a reasonable excuse for both requiring mmu_interval_notifier and shrinker callbacks at the same time as having to track asynchronous compute work using dma_fence. No driver outside of drivers/gpu should ever call dma_fence_wait in such contexts. 👀

👀 SEE ALSO 👀

• Kernel file ./drivers/dma-buf/dma-fence.c DMA fences overview(9)
• dma_fence_get_stub(9)
• dma_fence_allocate_private_stub(9)
• dma_fence_context_alloc(9)
• fence signalling annotation(9)
• dma_fence_begin_signalling(9)
• dma_fence_end_signalling(9)
• dma_fence_signal_timestamp_locked(9)
• dma_fence_signal_timestamp(9)
• dma_fence_signal_locked(9)
• dma_fence_check_and_signal_locked(9)
• dma_fence_check_and_signal(9)
• dma_fence_signal(9)
• dma_fence_wait_timeout(9)
• dma_fence_release(9)
• dma_fence_free(9)
• dma_fence_enable_signaling(9)
• dma_fence_add_callback(9)
• dma_fence_get_status(9)
• dma_fence_remove_callback(9)
• dma_fence_default_wait(9)
• dma_fence_wait_any_timeout(9)
• deadline hints(9)
• dma_fence_set_deadline(9)
• dma_fence_describe(9)
• dma_fence_init(9)
• dma_fence_init64(9)
• dma_fence_driver_name(9)
• dma_fence_timeline_name(9)

xoxo, your kernel bestie 💖 source/version: ./drivers/dma-buf · date: October 2026. slay and ship it 🫶