dma_fence_driver_name(9)

📦 version 7.3.1, in nixpkgs unstable

✨ dma_fence_driver_name(9) ✨

okay so this is a page from the Kernel API Manual (the 9 section, kernel API stuff, iykyk) and it's all about dma_fence_driver_name 💅

🌸 NAME 🌸

dma_fence_driver_name — get that driver name, bestie 💖

🦋 SYNOPSIS 🦋

const char __rcu * dma_fence_driver_name (struct dma_fence *fence );

🎀 ARGUMENTS 🎀

  • fence — the fence we're querying, like "hey girl who's your driver" 🫶

🔥 DESCRIPTION 🔥

So it returns the driver name that's backing the dma-fence implementation. Simple enough, right? ngl the name part is the easy part — it's the fine print that's giving main character energy 😭

IMPORTANT CONSIDERATION: the dma-fence contract is literally so strict about this. Access to driver-provided data (meaning data that is not directly embedded into the object itself) — things like dma_fence.lock and memory that the dma_fence.ops functions might access — is forbidden after the fence has been signalled. Drivers are allowed to free that data, and some do. 💀

So to make access safe, drivers are mandated to guarantee an RCU grace period between signalling the fence and freeing said data. No shortcuts, periodt.

Which means: access to the driver name is only valid inside a RCU locked section. The pointer MUST be both queried and USED ONLY WITHIN a SINGLE block guarded by the rcu_read_lock and rcu_read_unlock pair. Like, both. The same block. One block. Don't be out here grabbing the pointer in one place and using it somewhere else 🙈

🌈 SEE ALSO 🌈

Kernel file ./drivers/dma-buf/dma-fence.c, plus the whole friend group:

that's the whole page, bestie ✨💜 this one lives under ./drivers/dma-buf and it's dated October 2026 — go off, kernel docs 👑🦋 mwah 💋

📦 where this page comes from