dma_buf_invalidate_mappings(9)

💅 dma_buf_invalidate_mappings(9) — like, the Kernel API Manual page, bestie 🎀

okay so you found the dma_buf_invalidate_mappings page in the Kernel API Manual and you're like "what does this even do" — don't worry, I gotchu. Let's go ✨

---

🌸 NAME 🌸

dma_buf_invalidate_mappings — notify attachments that the DMA-buf is moving 🦋

---

✨ SYNOPSIS ✨

void dma_buf_invalidate_mappings (struct dma_buf *dmabuf );

---

🫶 ARGUMENTS 🫶

• dmabuf — [in] the buffer that is moving. that's it. that's the whole arg. 💖

---

👑 DESCRIPTION 👑

So the whole vibe here is: this function tells all the attachments "hey bestie, you need to destroy and recreate all your mappings" — like a full glow-up reset on their mappings, no cap. 🔥

Now it depends on what kind of attachment we're talking about:

• If the attachment is dynamic, then the dynamic importer is expected to invalidate any caches it has of the mapping result and perform a new mapping request before it's allowed to let the HW do any further DMA. like, redo the whole thing before touching hardware again, periodt. 💅
• If the attachment is pinned, then this informs the pinned importer that the underlying mapping is no longer available. And heads up — pinned importers may take this as a permanent revocation and never establish new mappings ever again 😭. So exporters, please do not trigger this lightly. it's giving "one wrong move and it's over."

---

okay now the important part, the timing of it all ⏳

Upon return importers may continue to access the DMA-buf memory. yep, it's not instant. The caller must do two additional waits to make sure the memory is truly no longer being accessed:

1. Until dma_resv_wait_timeout retires fences, the importer is allowed to fully access the memory.
2. Until the importer calls unmap, it is allowed to speculatively read-and-discard the memory. It must not write to the memory. 🚫

So if a caller wishes to use dma_buf_invalidate_mappings to fully stop access to the DMA-buf, it must wait for both. Dynamic callers can often get away with just the first one. 🍓

---

More rules, because of course there are 📋:

• All importers that provide an invalidate_mappings op must ensure that unmap is called within bounded time after the op. no dragging your feet, babe.
• Pinned importers that do not support an invalidate_mappings op will eventually perform unmap when they're done with the buffer — which may be an unbounded time from calling this function 😬. If you wanna keep those importers from attaching in the first place, dma_buf_attach_revocable is right there.
• Importers are free to request a new mapping in parallel as this function returns. slay, go off, do your thing 🔥

fr fr, just remember: this isn't a "everybody stop touching the memory instantly" button. It's a notification. The waiting is on you, bestie. 🙈

---

🌈 SEE ALSO 🌈

Kernel file ./drivers/dma-buf/dma-buf.c, plus the whole friend group: dma_buf_iter_begin(9), dma_buf_iter_next(9), implicit fence polling(9), dma_buf_set_name(9), dma buf device access(9), dma_buf_export(9), dma_buf_fd(9), dma_buf_fd_install(9), dma_buf_get(9), dma_buf_put(9), locking convention(9), dma_buf_dynamic_attach(9), dma_buf_attach(9), dma_buf_detach(9), dma_buf_pin(9), dma_buf_unpin(9), dma_buf_map_attachment(9), dma_buf_map_attachment_unlocked(9), dma_buf_unmap_attachment(9), dma_buf_unmap_attachment_unlocked(9), dma_buf_attach_revocable(9), cpu access(9), dma_buf_begin_cpu_access(9), dma_buf_end_cpu_access(9), dma_buf_mmap(9), dma_buf_vmap(9), dma_buf_vmap_unlocked(9), dma_buf_vunmap(9), dma_buf_vunmap_unlocked(9) 💜

---

okay bye bestie, go invalidate those mappings responsibly 💅✨

this lil page lives at ./drivers/dma-buf and it's dated October 2026 — the source/version and date, mentioned here like the good little footer that it is. 🧚‍♀️⭐