ww_mutex_loc...nterruptible(9)

📦 version 7.3.1, in nixpkgs unstable

💅 ww_mutex_lock_slow_interruptible — the "slow path but make it interruptible" moment 💅

okay so bestie, this is a page from the Kernel API Manual, and the vibe is: w/w mutexes, slowpath acquiring, and ✨signals✨. the star of the show is ww_mutex_lock_slow_interruptible, and no, the title up top being all ww_mutex_loc...nterruptible(9) is just the terminal being dramatic and truncating — we know her full name 💖

🌸 NAME 🌸

ww_mutex_lock_slow_interruptible — slowpath acquiring of the w/w mutex, interruptible 🎀

honestly? the name tells you the whole story. slowpath. interruptible. w/w mutex. slay.

✨ SYNOPSIS ✨

int ww_mutex_lock_slow_interruptible (struct ww_mutex *lock , struct ww_acquire_ctx *ctx );

that's it, that's the whole call. two args, one int coming back at you 🫶

🎀 ARGUMENTS 🎀

  • lock — the mutex to be acquired. the actual thing you're fighting for, bestie 💅
  • ctx — w/w acquire context. the whole bookkeeping situation that tells the w/w machinery who's holding what.

🦋 DESCRIPTION 🦋

okay so here's what's going down: this function acquires a w/w mutex with the given context after a die case. yes, "die case" — that's the term, we don't make the rules 😭

it will sleep until the lock becomes available, and it returns 0 when the lock has been acquired. icon behavior, honestly. but if a signal arrives while it's waiting for the lock, then this function returns -EINTR. so like... you were waiting, someone poked you with a signal, you bail. periodt.

now the rules of the house 🏠

the caller must have released all w/w mutexes already acquired with the context, and then call this function on the contended lock. no holding onto your other locks while you do this, bestie, that's not the vibe.

afterwards, the caller may continue to (re)acquire the other w/w mutexes it needs with ww_mutex_lock. and here's a little tip that's literally in the docs so it's canon: the -EALREADY return code from ww_mutex_lock can be used to avoid locking this contended mutex twice. handy!! 🔥

and now the hard ✨no-nos✨ — these are forbidden, and forbidden is forbidden:

  • it is forbidden to call this function with any other w/w mutexes associated with the given context held 🚫
  • it is forbidden to call this on anything else than the contending mutex 🚫

like, genuinely, do not. this is not a "haha maybe" situation, it's a "the docs said forbidden twice" situation 💀

also a fun little note before you go: the slowpath lock acquiring can also be done by calling ww_mutex_lock_interruptible directly. this function here is simply to help w/w mutex locking code readability by clearly denoting the slowpath. so basically it's the same energy, but it labels the vibe for the next person reading your code. main character documentation energy, we love to see it 👑

🌈 SEE ALSO 🌈

Kernel file ./include/linux/ww_mutex.h, plus the whole friend group:

go read them, they're all connected, iykyk 💜

and that's the page bestie 🫶 this came out of ./include/linux and it's dated October 2026 — so yeah, it's giving future-manpage, it's giving timeless kernel lore, and it's giving ww_mutex_loc...nterruptible(9) in the corner being extra. mwah 💋🌸

📦 where this page comes from