dma_buf_pin(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– dma_buf_pin(9) πŸ’–

okay so bestie, welcome to the Kernel API Manual β€” yes that's the manual name, we're being official for like two seconds β€” and today's main character is dma_buf_pin. It locks down a DMA-buf. That's it. That's the vibe. πŸŽ€


✨ NAME ✨

dma_buf_pin β€” lock down the DMA-buf, no cap πŸ”’


🌸 SYNOPSIS 🌸

int dma_buf_pin(struct dma_buf_attachment *attach);

πŸ¦‹ ARGUMENTS πŸ¦‹

  • attach [in] β€” the attachment that should be pinned. literally the whole point, she's the one getting locked down 🫢

πŸ’… DESCRIPTION πŸ’…

okay so listen, this is exclusive. Only dynamic importers may call this β€” and by dynamic importers I mean the ones who set up attach with dma_buf_dynamic_attach. If that's not you, this is not your function, periodt. πŸ’€

And even if you are a dynamic importer, this is for limited use cases β€” like scanout. Not for temporary pin operations. like, temporary pinning? different thing, not this, don't try it here. πŸ™ˆ

Also, and this is important, bestie: it is not permitted to let userspace pin arbitrary amounts of buffers through this interface. Arbitrary amounts? no ma'am. that's a hard no. put it down. 🌈

And when you're done pinning β€” and you will be done eventually β€” the buffers must be unpinned by calling dma_buf_unpin. it's giving "clean up after yourself" energy and honestly? iconic. ✨


πŸ‘‘ RETURN πŸ‘‘

  • 0 on success πŸŽ‰
  • a negative error code on failure 😭

🧚 SEE ALSO 🧚

the whole friend group, fr fr. kernel file ./drivers/dma-buf/dma-buf.c plus:


that's the whole page, bestie, u ate that πŸ’…βœ¨

and before u go β€” cute sign-off time πŸŽ€ this one lives at ./drivers/dma-buf, it's stamped October 2026, and it's filed under dma_buf_pin(9) in the Kernel API Manual. mwah, go pin something responsibly πŸ«ΆπŸ’–

πŸ“¦ where this page comes from