dma_fence_s...stamp_locked(9)

📦 version 7.3.1, in nixpkgs unstable

💅 dma_fence_signal_timestamp_locked — the Kernel API Manual, but make it cute ✨

okay so bestie, buckle up — we're in the Kernel API Manual today and this one is genuinely iconic. it's dma_fence_signal_timestamp_locked(9) and it's giving "i'm the locked version of that other function you already know" 🎀

🌸 NAME 🌸

dma_fence_signal_timestamp_locked — signal completion of a fence 💖

✨ SYNOPSIS ✨

void dma_fence_signal_timestamp_locked (struct dma_fence *fence ,
ktime_t timestamp );

like, that's it. two args. no cap. 🫶

🦋 ARGUMENTS 🦋

  • fence — the fence you're signalling, bestie. the main character, fr fr.
  • timestamp — the fence signal timestamp, and it lives in the kernel's CLOCK_MONOTONIC time domain. don't forget the domain part, it matters 💀

🔥 DESCRIPTION 🔥

okay so here's the vibe: you call this and it signals completion for software callbacks on a fence. what that actually does is unblock dma_fence_wait calls and run all the callbacks that were added with dma_fence_add_callback. so like, everybody waiting in the group chat finally gets the message. 📬

you can call it multiple times, but — and this is the key part — a fence can only go from the unsignaled state to the signaled state and not back. so it will only be effective the first time. periodt. the later calls are just there existing, doing nothing, lowkey ghosted. 👻

it also sets the timestamp you pass in as the fence signal timestamp. ⏰

🚨 the big one: unlike dma_fence_signal_timestamp, this function must be called with dma_fence.lock held. like, that's not optional. that's the whole reason _locked is in the name, iykyk. 🔒

🌈 SEE ALSO 🌈

like, that's a whole friend group right there. go say hi. 🫶✨

aaaand that's the page!! 🎀 this one lives in ./drivers/dma-buf and it's dated October 2026 — so yeah, future vibes only. mwah, bye bestie, go hold that lock 💅💖

📦 where this page comes from