dma_buf_map_attachment(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… dma_buf_map_attachment β€” the Kernel API Manual page, bestie edition

okay so this is dma_buf_map_attachment(9) from the Kernel API Manual and it's lowkey one of the most important little functions in the dma-buf world, so like… pay attention bestie 🫢

✨ NAME ✨

dma_buf_map_attachment β€” returns the scatterlist table of the attachment, mapped into device address space. it's literally just a wrapper for map_dma_buf() of the dma_buf_ops. that's it. that's the whole vibe. πŸ¦‹

🌸 SYNOPSIS 🌸

struct sg_table * dma_buf_map_attachment (struct dma_buf_attachment
*attach , enum dma_data_direction direction );

πŸŽ€ ARGUMENTS πŸŽ€

  • attach [in] β€” the attachment whose scatterlist we're returning, bestie. this is the main character here πŸ‘‘
  • direction [in] β€” the direction of the DMA transfer. yes it matters, no you can't skip it πŸ™ˆ

πŸ’– DESCRIPTION πŸ’–

so what does it actually do? it returns an sg_table containing the scatterlist to be returned β€” and if something goes wrong it returns ERR_PTR on error. also!! it may return -EINTR if it gets interrupted by a signal. rude but true πŸ’€

on success, the DMA addresses and lengths in the returned scatterlist are PAGE_SIZE aligned. slay. ✨

every mapping must be unmapped by using dma_buf_unmap_attachment. no cap, this is not optional. and here's the tea: the underlying backing storage is pinned for as long as a mapping exists, so users/importers should not hold onto a mapping for undue amounts of time. like, don't be clingy with your mappings fr fr 😭

Important: dynamic importers must wait for the exclusive fence of the struct dma_resv attached to the DMA-BUF first. this is the big one, don't skip it πŸ™

πŸ¦‹ SEE ALSO πŸ¦‹


and that's the whole page!! this icon lives in ./drivers/dma-buf and this particular rendering is dated October 2026 in the Kernel API Manual β€” go read the rest of the dma-buf girlies, they all ate πŸ’…πŸ”₯⭐

πŸ“¦ where this page comes from