ww_mutex_lock_interruptible(9)

📦 version 7.3.1, in nixpkgs unstable

💅 ww_mutex_lock_interruptible — Kernel API Manual ✨

okay so bestie, welcome to the ww_mutex_lock_interruptible page from the Kernel API Manual 📖💖 this one is all about grabbing a w/w mutex the interruptible way, and honestly it's giving "polite but firm" energy. let's get into it 🎀

✨ SYNOPSIS ✨

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

that's the whole signature, no cap 🫶

🌸 ARGUMENTS 🌸

  • lock — the mutex to be acquired 🔒 like, the actual thing you're trying to get your hands on
  • ctx — the w/w acquire context 💫 the vibe-check context that keeps the whole w/w thing coordinated

💜 DESCRIPTION 💜

Lock the w/w mutex exclusively for this task. exclusive, bestie, meaning it's yours and nobody else's while you hold it 👑

Deadlocks within a given w/w class of locks are detected and handled with the wait/die algorithm 😤 and yes that's as dramatic as it sounds:

  • if the lock isn't immediately available, this function will either sleep until it is (the wait case) 😴
  • or it selects the current context for backing off by returning -EDEADLK (the die case) 💀

Trying to acquire the same lock with the same context twice is also detected, and it gets signalled by returning -EALREADY 🙈 like, you already have it, girl.

Returns 0 if the mutex was successfully acquired 🎉 And if a signal arrives while waiting for the lock, then this function returns -EINTR ⚡️ (that's the "interruptible" part of the whole deal, iykyk).

⚠️ In the die case the caller must release all currently held w/w mutexes for the given context and then wait for this contending lock to be available by calling ww_mutex_lock_slow_interruptible. Alternatively callers can opt to not acquire this lock and proceed with trying to acquire further w/w mutexes (e.g. when scanning through lru lists trying to free resources).

🦋 the rules of ownership 🦋

okay this part is important so listen up fr fr:

  • The mutex must later on be released by the same task that acquired it. no passing it off to your friend, bestie 🫶
  • The task may not exit without first unlocking the mutex. like, you can't just dip 🏃‍♀️
  • Also, kernel memory where the mutex resides must not be freed with the mutex still locked. nope. not allowed. 🔥
  • The mutex must first be initialized (or statically defined) before it can be locked.
  • memset-ing the mutex to 0 is not allowed 🚫🙅‍♀️ (that's an absolute no)
  • The mutex must be of the same w/w lock class as was used to initialize the acquire context. matching vibes only ✨
💅 And a mutex acquired with this function must be released with ww_mutex_unlock.

🌈 SEE ALSO 🌈

Kernel file ./include/linux/ww_mutex.h and all these iconic little functions:

and that's the page!! 🎀✨

this whole thing lives in ./include/linux 📁, and the version/date situation is October 2026 — so like, future girly vibes, we love to see it 🦋💖 mwah, go forth and lock responsibly 💅👑

📦 where this page comes from