rt_mutex_wait_proxy_lock(9)

📦 version 7.3.1, in nixpkgs unstable

✨ rt_mutex_wait_proxy_lock(9) ✨

okay bestie, so we're deep in the Kernel API Manual today and this one is a whole mood — it's the "wait for the lock somebody else started for you" call 💅. Buckle up, it's giving very niche-but-iconic kernel-locking energy.

🌸 SYNOPSIS 🌸

int rt_mutex_wait_proxy_lock (struct rt_mutex_base *lock , struct
hrtimer_sleeper *to , struct rt_mutex_waiter *waiter );

🎀 ARGUMENTS 🎀

  • lock — the rt_mutex we were woken on. literally the lock in question, bestie 🫶
  • to — the timeout, or null if there isn't one. heads up: the hrtimer should already have been started before you get here ⏰
  • waiter — the pre-initialized rt_mutex_waiter. yes, pre-initialized — do that part first, don't show up unprepared 😭

🦋 DESCRIPTION 🦋

So here's the vibe: this call waits for the lock acquisition that was started on our behalf by rt_mutex_start_proxy_lock ✨. It's a team-effort situation — someone else kicked it off, and now we're just here waiting for it to land.

💀 important: upon failure, the caller must call rt_mutex_cleanup_proxy_lock. not optional. no cap. clean up after yourself.

Also, this is a special API call for PI-futex support — that's the whole reason it exists, iykyk 👑

🔥 RETURN 🔥

  • 0 — success, we ate 💖
  • <0 — error, and it's one of -EINTR or -ETIMEDOUT 🙈

🌈 SEE ALSO 🌈

Kernel file ./kernel/locking/rtmutex_api.c — the source of truth, go read it bestie 📖

okay that's the whole page, mwah 💋 — brought to you by ./kernel/locking, the October 2026 edition of rt_mutex_wait_proxy_lock(9). go wait on that lock, you gorgeous icon, and remember to clean up 🎀✨

📦 where this page comes from