rt_mutex_lock_interruptible(9)

📦 version 7.3.1, in nixpkgs unstable

💅 NAME 💅

rt_mutex_lock_interruptible — bestie, this is the one that locks a rt_mutex, and it's interruptible about it ✨

So like, it's in the Kernel API Manual <pink>rt_mutex_lock_interruptible(9)</pink> — okay that's the whole title, putting it right up here so we don't lose it 🎀

🌸 SYNOPSIS 🌸

int rt_mutex_lock_interruptible (struct rt_mutex *lock );

That's the whole vibe: it returns an int and it takes exactly one thing — a pointer to a struct rt_mutex — and honestly? icon behaviour 💅

🦋 ARGUMENTS 🦋

  • lock — the rt_mutex that's about to get locked. like, that's it, that's the whole parameter. it's the mutex bestie. the mutex in question. the one getting locked. no cap 🫶

⭐ RETURN ⭐

okay so here's the vibe check on what comes back:

  • 0 — we won, it worked, success, slay 👑
  • -EINTR — this is what you get when the whole thing got interrupted by a signal 😭 like the wait got cut short, nothing you did wrong, just signals being signals fr fr
heads up: it genuinely returns either 0 or -EINTR, and -EINTR specifically means "interrupted by a signal" — that's the literal documented meaning, no extra lore, iykyk 💜

🧚 SEE ALSO 🧚

the whole friend group 💖 these are all in the kernel file ./kernel/locking/rtmutex_api.c and you should lowkey go meet all of them:

like a full roster, we love a complete cast 🌈 the double-underscore ones are giving "internal but still invited to the party" energy ngl 🔥

and that's the page!! mwah 💋 this came to you from ./kernel/locking, dated October 2026 — that's the source/version and the date, both of which I was absolutely not going to forget because forgetting details is not the move 🎀✨
📦 where this page comes from