rcu_read_lock_bh(9)

📦 version 7.3.1, in nixpkgs unstable

💅 rcu_read_lock_bh — the Kernel API Manual, bestie edition 🎀

Okay so picture this: you're in the kernel, you need an RCU read-side critical section, and you also need softirqs to chill out for a sec. That's literally this function. Welcome to rcu_read_lock_bh 🦋

✨ NAME ✨

rcu_read_lock_bh — mark the beginning of an RCU-bh critical section 👑

🌸 SYNOPSIS 🌸

void rcu_read_lock_bh (void );

🎀 ARGUMENTS 🎀

  • void — no arguments. Not a single one. She takes nothing and gives everything 💖

💫 DESCRIPTION 💫

So here's the tea ☕: this one is equivalent to rcu_read_lock, except it also disables softirqs. Two-for-one, no cap.

And here's the part people forget: anything else that disables softirqs can also serve as an RCU read-side critical section. So if some other code path is already shutting softirqs down, congrats, you're already in the club 🫶

🚨 BUT — and I cannot stress this enough — that equivalence applies only to v5.0 and later. Before v5.0, rcu_read_lock and rcu_read_lock_bh were completely unrelated. Like, not even mutuals. So if you're kicking it on an older kernel, do NOT assume they're the same vibe. Fr fr 😭

Also, huge one: rcu_read_lock_bh and its matching rcu_read_unlock_bh must occur in the same context 🌈 For example, it is illegal to invoke rcu_read_unlock_bh from one task if the matching rcu_read_lock_bh was invoked from some other task. That's not a "eh, probably fine" situation, that's a no. Matching lock and unlock, same task, periodt 💅

👀 SEE ALSO 👀

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

🧚 sign-off 🧚

This icon of a page lives in ./include/linux, and it's stamped October 2026 — rcu_read_lock_bh(9). Go forth, lock that bh section, and remember: same context, bestie. Always. 💜🔥

📦 where this page comes from