ww_mutex_lock(9)

💅 ww_mutex_lock — the girlies' guide to grabbing the w/w mutex ✨

okay so this is from the Kernel API Manual, section 9 (kernel interfaces, iykyk), and bestie, we're about to learn how to take a w/w mutex the correct way. no cap. 🎀

---

✨ NAME ✨

ww_mutex_lock — acquire the w/w mutex. that's it. that's the whole vibe. 💖

---

🦋 SYNOPSIS 🦋

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

---

🌸 ARGUMENTS 🌸

• lock — the mutex to be acquired. the thing you want. your main character mutex. 👑
• ctx — w/w acquire context, or NULL to acquire only a single lock. yeah, NULL is totally valid here — it literally just means "one lock only, no group chat." 🫶

---

💜 DESCRIPTION 💜

Lock the w/w mutex exclusively for this task. nobody else gets in. periodt. 🔥

Deadlocks within a given w/w class of locks are detected and handled with the wait/die algorithm. so like, if the lock isn't immediately available, this function will either:

• sleep until it is (that's the wait case 😴), or
• select the current context for backing off by returning -EDEADLK (that's the die case 💀).

Trying to acquire the same lock with the same context twice is also detected and signalled by returning -EALREADY. happens to the best of us, ngl. 🙈

Returns 0 if the mutex was successfully acquired. slay. ✨

---

🧚 the die case, explained (because it's giving complications)

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.

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. sometimes you just gotta let it go and move on, bestie. 🦋

---

⚠️ rules, rules, rules (do NOT skip these, fr fr)

• The mutex must later on be released by the same task that acquired it. no passing it off to your friend. 👯
• The task may not exit without first unlocking the mutex.
• Kernel memory where the mutex resides must not be freed with the mutex still locked.
• The mutex must first be initialized (or statically defined) before it can be locked.
• memset-ing the mutex to 0 is not allowed. like, don't. 💀
• The mutex must be of the same w/w lock class as was used to initialize the acquire context. it's giving "matching set energy." 🎀

A mutex acquired with this function must be released with ww_mutex_unlock. that's the whole point of the cycle, okay?? 🔁

---

🎀 SEE ALSO 🎀

• Kernel file ./include/linux/ww_mutex.h
• ww_mutex_init(9)
• ww_acquire_init(9)
• ww_acquire_done(9)
• ww_acquire_fini(9)
• ww_mutex_lock_interruptible(9)
• ww_mutex_lock_slow(9)
• ww_mutex_lock_slow_interruptible(9)
• ww_mutex_is_locked(9)

all the friends in the same friend group, honestly. go read them. 📚

---

and that's the tea! 🍓 this iconic little page lives at ./include/linux, dated October 2026, and it's literally called ww_mutex_lock(9) — ok bye, love you, lock responsibly! 💅💖✨