mutex_lock(9)

📦 version 7.3.1, in nixpkgs unstable

💅 mutex_lock(9) — Kernel API Manual

Okay so bestie, welcome to the mutex_lock(9) page, we're doing kernel locking today and honestly? It's giving main character energy. Sit down, hydrate, let's go. 🫶

✨ NAME ✨

mutex_lock — acquire the mutex 🔒

🌸 SYNOPSIS 🌸

void mutex_lock (struct mutex *lock );

🎀 ARGUMENTS 🎀

  • lock — the mutex you're about to acquire, i.e. the whole reason we're here 💖

🦋 DESCRIPTION 🦋

So here's the vibe: you call this and it locks the mutex exclusively for this task. Just you. Nobody else. If the mutex isn't available right now? It does not panic, it does not spin, it just sleeps until it can get it. Very demure. Very mindful. 😴

Now the rules, and bestie, these are not optional:

  • The mutex must later on be released by the same task that acquired it. Like, the exact same one. No sending your friend to unlock it for you.
  • Recursive locking is not allowed — do not try to lock the thing you already locked, it will not go well for you, fr fr.
  • The task may not exit without first unlocking the mutex.
  • Also, 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. Non-negotiable.
  • And ngl, memset-ing the mutex to 0 is not allowed. Do not do it. I'm serious. 💀
Okay so there's actually help for all of this: the CONFIG_DEBUG_MUTEXES .config option turns on debugging checks that will enforce the restrictions, and it'll also do deadlock debugging for you. Iconic of it, honestly. 👑

Also, for the record: this function is similar to (but not equivalent to) down.

👑 SEE ALSO 👑

Kernel file ./kernel/locking/mutex.c, plus all these besties:

That's the whole page, bestie — go lock something responsibly (and unlock it with the same task, please 🙈). This one lives in ./kernel/locking, and it's dated October 2026, so it's basically brand new. Slay, bye! 💅✨🎀

📦 where this page comes from