STRUCT DMA_BUF_EXPORT_SYNC_FILE(9)

💅 struct dma_buf_export_sync_file (9) 💅

okay bestie, buckle up — this is the Kernel API Manual page for struct dma_buf_export_sync_file, and it's lowkey one of the most useful little structs in the dma-buf cinematic universe. grab a matcha, we're doing this 🍓

---

✨ NAME ✨

struct dma_buf_export_sync_file — Get a sync_file from a dma-buf 💖

---

🦋 SYNOPSIS 🦋

struct dma_buf_export_sync_file {
    __u32 flags;
    __s32 fd;
 };

like, that's it. two fields. tiny. iconic. main character energy in four lines ✨

---

🎀 Members 🎀

• flags — Read/write flags 🔥

Must be DMA_BUF_SYNC_READ, DMA_BUF_SYNC_WRITE, or both. no mixing and matching beyond that, ok?

If DMA_BUF_SYNC_READ is set and DMA_BUF_SYNC_WRITE is not set, the returned sync file waits on any writers of the dma-buf to complete. Waiting on the returned sync file is equivalent to poll with POLLIN. so it's giving "tell me when the writers are done" ✍️

If DMA_BUF_SYNC_WRITE is set, the returned sync file waits on any users of the dma-buf (read or write) to complete. Waiting on the returned sync file is equivalent to poll with POLLOUT. If both DMA_BUF_SYNC_WRITE and DMA_BUF_SYNC_READ are set, this is equivalent to just DMA_BUF_SYNC_WRITE. yeah — WRITE ate READ, that's the rule 💀

• fd — Returned sync file descriptor 🫶

that's your prize. the fd you waited for.

---

🌸 Description 🌸

Userspace can perform a DMA_BUF_IOCTL_EXPORT_SYNC_FILE to retrieve the current set of fences on a dma-buf file descriptor as a sync_file. 🧚

So here's the vibe: CPU waits via poll or other driver-specific mechanisms typically wait on whatever fences are on the dma-buf at the time the wait begins. This is similar except that it takes a snapshot of the current fences on the dma-buf for waiting later instead of waiting immediately. not me taking a screenshot of the fences for later 📸 This is useful for modern graphics APIs such as Vulkan which assume an explicit synchronization model but still need to inter-operate with dma-buf. no cap, Vulkan said "explicit sync or nothing" and dma-buf said "bet."

The intended usage pattern is the following:

1. Export a sync_file with flags corresponding to the expected GPU usage via DMA_BUF_IOCTL_EXPORT_SYNC_FILE.
2. Submit rendering work which uses the dma-buf. The work should wait on the exported sync file before rendering and produce another sync_file when complete.
3. Import the rendering-complete sync_file into the dma-buf with flags corresponding to the GPU usage via DMA_BUF_IOCTL_IMPORT_SYNC_FILE.

⚠️ okay this part matters, listen up: unlike doing implicit synchronization via a GPU kernel driver's exec ioctl, the above is not a single atomic operation. If userspace wants to ensure ordering via these fences, it is the respnosibility of userspace to use locks or other mechanisms to ensure that no other context adds fences or submits work between steps 1 and 3 above. (yes, "respnosibility" — the original page said it like that, we're keeping the lore 🙈) so like. lock it yourself. don't come crying to the kernel. 💀

---

🌈 SEE ALSO 🌈

• Kernel file ./include/uapi/linux/dma-buf.h — struct dma_buf_sync(9), struct dma_buf_import_sync_file(9) 👑

go read those too, iykyk 💜

---

and that's the whole page bestie, slay 💅 from the Kernel API Manual, dropped from ./include/uapi/linux, dated October 2026 — see you in the group chat, mwah 🎀💖✨