dma_resv_for...nce_unlocked(9)

📦 version 7.3.1, in nixpkgs unstable

✨ dma_resv_for_each_fence_unlocked(9) ✨

okay so real talk, bestie, this page lives in the Kernel API Manual and it's about the unlocked fence iterator. yes i said unlocked. yes it's as chaotic as it sounds. buckle up 🎀

🌸 NAME 🌸

dma_resv_for_each_fence_unlocked — the unlocked fence iterator, aka the one that does NOT hold the lock and honestly? iconic for it 💅

⭐ SYNOPSIS ⭐

dma_resv_for_each_fence_unlocked (cursor , fence );

🦋 ARGUMENTS 🦋

  • cursor — a struct dma_resv_iter pointer. this is your little iterator buddy that keeps track of where you're at, okay? you gotta feed it the right struct or it's gonna have a bad time 🙈
  • fence — the current fence. like, the one you're lookin' at right now in this loop iteration. that's her. that's the fence 💖

✨ DESCRIPTION ✨

so what this does is: you iterate over the fences in a struct dma_resv object without holding dma_resv.lock, and instead you're using RCU. no cap, that's the whole bit. that's the vibe 🌈

before you go anywhere near the loop, the cursor needs to be initialized with dma_resv_iter_begin, and when you're done-done you gotta clean things up with dma_resv_iter_end. and inside the iterator, a reference to the dma_fence is held and the RCU lock is dropped. so like, that's the arrangement, bestie 🫶

⚠️ ok now the important part, listen up: beware that the iterator can be restarted when the struct dma_resv for cursor is modified. so if your code accumulates statistics or similar, you literally have to check for this with dma_resv_iter_is_restarted. do not skip this. it's giving "consequences" 😭

and for that exact reason, prefer the lock iterator dma_resv_for_each_fence whenever possible. like, if you can use the locked one, use the locked one. that's the recommendation, fr fr 👑

🔥 SEE ALSO 🔥

and that's the whole page, bestie 💜 this one shipped out of ./include/linux back in October 2026 — go forth and iterate responsibly, mwah 🧚💖

📦 where this page comes from