rt_mutex_cleanup_proxy_lock(9)

📦 version 7.3.1, in nixpkgs unstable

💅 rt_mutex_cleanup_proxy_lock(9)

okay so this is a page from the Kernel API Manual, and bestie, it's giving "the cleanup crew of lock acquisition" energy. like, this function shows up after things went sideways and it's here to tidy up. no cap. 🧹✨

🌸 NAME 🌸

rt_mutex_cleanup_proxy_lock — literally the "cleanup failed lock acquisition" girlie. that's her whole job. 💖

✨ SYNOPSIS ✨

bool rt_mutex_cleanup_proxy_lock (struct rt_mutex_base *lock , struct
       rt_mutex_waiter *waiter );

like, she takes two things and returns a bool. that's the vibe. 🫶

🎀 ARGUMENTS 🎀

  • lock — the rt_mutex we were woken on. yes, that one. the one that woke us up. 👀
  • waiter — the pre-initialized rt_mutex_waiter. already init'd ahead of time, so don't come at her with an uninitialized one fr fr.

🦋 DESCRIPTION 🦋

So here's the situation, bestie. This is the attempt to clean up after a failed __rt_mutex_start_proxy_lock or rt_mutex_wait_proxy_lock. like, something didn't go the way we wanted, and now we're doing damage control. 😭

And here's the tea: unless we acquired the lock, we're still enqueued on the wait-list and can in fact still be granted ownership until we're removed. so the plot twist is that we can find out we are in fact the owner, and in that case we must disregard the rt_mutex_wait_proxy_lock failure. main character behavior honestly. 👑

Also super important: this is a Special API call for PI-futex support. so like, iykyk. 💅

🔥 RETURN 🔥

  • true — did the cleanup, we done. ✅ periodt.
  • false — we acquired the lock after rt_mutex_wait_proxy_lock returned, so the caller should disregard its return value. like, that return value is not the moment anymore, okay? 🙈

🌈 SEE ALSO 🌈

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

bestie, that's the whole page!! stay hydrated, read your lock semantics, and remember: ./kernel/locking, October 2026, rt_mutex_cleanup_proxy_lock(9). mwah 💋💖🎀

📦 where this page comes from