SAFE EXTERNAL ACCESS TO DRIVER PROVIDED OBJECT MEMBERS(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– Safe external access to driver provided object members πŸ’–

okay so bestie, this page is from the Kernel API Manual, and it is the Safe external access to driver provided object members(9) one. it is lowkey a safety briefing for dma-fence data, and it is giving β€œdo not touch after signal” energy πŸ’…

here is the rule, no cap: all data not stored directly in the dma-fence object β€” stuff like dma_fence.lock and memory that functions in the dma_fence.ops table might access β€” MUST NOT be accessed after the fence has been signalled. why? because after that point drivers are allowed to free it πŸ’€

any code that accesses that data through the dma-fence API (or directly, which is discouraged) MUST make sure the complete access is contained within an rcu_read_lock and rcu_read_unlock pair. like, wrap the whole thing, bestie 🫢

some dma-fence API handles this automatically, while other, as for example dma_fence_driver_name and dma_fence_timeline_name, leave that responsibility to the caller. so those two are not gonna hold your hand β€” you are the main character of the RCU lock ✨

to enable this scheme to work drivers MUST ensure a RCU grace period elapses between signalling the fence and freeing the said data. that is the whole tea 🍡


🌸 SEE ALSO 🌸

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


and that is the whole page, bestie πŸ’– source/version: ./include/linux Β· date: October 2026. stay safe and keep your RCU locks close. mwah πŸ’‹

πŸ“¦ where this page comes from