rt_mutex_init_proxy_locked(9)

📦 version 7.3.1, in nixpkgs unstable

💅 rt_mutex_init_proxy_locked — the kernel API manual, but make it make sense

okay so bestie, we're in the Kernel API Manual today and the star of the show is rt_mutex_init_proxy_locked(9). yes it's a mouthful. no you don't have to say it out loud. 🎀

✨ NAME ✨

rt_mutex_init_proxy_locked — initialize and lock a rt_mutex on behalf of a proxy owner 🫶

like, you're doing the locking, but the credit goes to someone else. main character energy by proxy, literally.

🌸 SYNOPSIS 🌸

void rt_mutex_init_proxy_locked (struct rt_mutex_base *lock , struct task_struct *proxy_owner );

that's it. that's the whole signature. no return value, we just vibe. ✨

🦋 ARGUMENTS 🦋

  • lock — the rt_mutex to be locked. yes, the actual mutex. the thing itself. 🔥
  • proxy_owner — the task to set as owner. so like, the mutex gets locked but this task's name is on the lease. iykyk. 👑

💜 DESCRIPTION 💜

No locking. Caller has to do serializing itself. like, the function is not gonna hold your hand here, bestie — you do the serializing, it just does the init-and-lock thing. 😭

This is a Special API call for PI-futex support. it initializes the rtmutex and assigns it to proxy_owner. 💫

and here's the cute part: concurrent operations on the rtmutex are not possible at this point, because the pi_state which contains the rtmutex is not yet visible to other tasks. so nobody else can even see it yet. it's giving private account, no followers, zero drama. 🙈

not me stressing the "no locking" bit again but fr fr — the serialization is your job, not the function's. don't come for this API when it doesn't do it for you. 💀

🧚 SEE ALSO 🧚

Kernel file ./kernel/locking/rtmutex_api.c — and the whole friend group:

okay that's the whole page, you ate that 🍓

and a little sign-off for the credits stans: this one lives in ./kernel/locking, dated October 2026, page rt_mutex_init_proxy_locked(9). slay. 💅👑🌈

📦 where this page comes from