DMA BUF DEVICE ACCESS(9)

📦 version 7.3.1, in nixpkgs unstable

💅 dma buf device access — a Kernel API Manual moment (section 9, bestie)

okay so picture this: you're a device, you want DMA access to a shared DMA buffer, and you're like "how do I even". girl, the usual sequence of operations is actually pretty simple, no cap. let me walk you through it 🫶

✨ the sequence (step by step, we love a process)

  1. the exporter era — the exporter defines their exporter instance using DEFINE_DMA_BUF_EXPORT_INFO and then calls dma_buf_export to wrap a private buffer object into a dma_buf. then it exports that dma_buf to userspace as a file descriptor by calling dma_buf_fd. iconic behavior, honestly 🎀
  2. sharing is caring — userspace passes this file-descriptor to all the drivers it wants this buffer shared with. first the file descriptor gets converted to a dma_buf using dma_buf_get. then the buffer is attached to the device using dma_buf_attach. bestie networking but for buffers 💅
lowkey important: up to this stage the exporter is still free to migrate or reallocate the backing storage. so don't get attached (pun intended) — it can still move 😭
  1. DMA time — once the buffer is attached to all devices, userspace can initiate DMA access to the shared buffer. in the kernel this is done by calling dma_buf_map_attachment and dma_buf_unmap_attachment. slay, map it and unmap it, that's the whole vibe ✨
  2. the clean exit — once a driver is done with a shared buffer it needs to call dma_buf_detach (after cleaning up any mappings!) and then release the reference it acquired with dma_buf_get by calling dma_buf_put. no ghosting your references, that's so not the move 🙈

🌸 the fine print

for the detailed semantics that exporters are expected to implement, see dma_buf_ops. that's where the actual rules live, iykyk 👑

🦋 SEE ALSO

and that's the whole page, bestie, you ate that 💖 this little gem lives over in ./drivers/dma-buf and it's stamped October 2026 — go off, kernel docs, periodt ✨👑

📦 where this page comes from