rcu_read_lock_held_common(9)

📦 version 7.3.1, in nixpkgs unstable

💅 rcu_read_lock_held_common — kernel api manual, bestie edition 🎀

okay so this is rcu_read_lock_held_common(9) from the Kernel API Manual and honestly? it's giving "am I actually in an RCU-sched read-side critical section or am I delulu" energy. let's get into it ✨

🌸 NAME 🌸

rcu_read_lock_held_common — might we be in RCU-sched read-side critical section? 🤔

✨ SYNOPSIS ✨

bool rcu_read_lock_held_common (bool *ret );

🦋 ARGUMENTS 🦋

  • ret — the best guess answer, but ONLY when lockdep can't be relied on. like, it's the backup plan, the understudy, the "if the main character doesn't show up" answer 💅

💖 DESCRIPTION 💖

okay so here's the vibe check. this function returns true if lockdep must be ignored, and in that case *ret holds the best guess described down below 👇. otherwise it returns false, and in that case *ret tells the caller literally nothing — nope, nada, zero information — and the caller should instead go consult lockdep directly. no cap. 🙈

if CONFIG_DEBUG_LOCK_ALLOC is selected, it sets *ret to nonzero iff we're in an RCU-sched read-side critical section. if CONFIG_DEBUG_LOCK_ALLOC is not around? then this just assumes we're in an RCU-sched read-side critical section unless it can prove otherwise. icon behavior honestly. also note that disabling of preemption (including disabling irqs) counts as an RCU-sched read-side critical section 👑 — this whole thing is super useful for debug checks in functions that required that they be called within an RCU-sched read-side critical section. periodt.

check debug_lockdep_rcu_enabled to prevent false positives during boot and while lockdep is disabled 🫶 (we love a preemptive vibe check).

💀 real talk though: note that if the CPU is in the idle loop from an RCU point of view (ie: that we are in the section between ct_idle_enter and ct_idle_exit) then rcu_read_lock_held sets *ret to false even if the CPU did an rcu_read_lock. the reason for this is that RCU ignores CPUs that are in such a section, considering these as in extended quiescent state, so such a CPU is effectively never in an RCU read-side critical section regardless of what RCU primitives it invokes. literally never, no matter how hard it tries 😭

and the way this state of affairs is required — we need to keep an RCU-free window in idle where the CPU may possibly enter into low power mode. this way we can notice an extended quiescent state to other CPUs that started a grace period 🌈. otherwise we would delay any grace period as long as we run in the idle task. not slay. not it.

similarly (fr fr), we avoid claiming an RCU read lock held if the current CPU is offline. offline CPU said "not me, not today" ✋

🔥 SEE ALSO 🔥

kernel file ./kernel/rcu/update.c plus these icons:

the whole friend group, obsessed 💜

that's the whole page bestie, brought to you by ./kernel/rcu, dated October 2026, serving rcu_read_lock_held_common(9) realness 💅✨ go be iconic in your critical section 🧚💖

📦 where this page comes from