srcu_read_lock_held(9)

📦 version 7.3.1, in nixpkgs unstable

💅 srcu_read_lock_held

ok so this is a page from the Kernel API Manual, bestie, and it's about srcu_read_lock_held(9) — the little guy that tells you whether you might be hanging out in an SRCU read-side critical section. let's get into it 🎀

✨ NAME ✨

srcu_read_lock_held — might we be in SRCU read-side critical section? 👀

🌸 SYNOPSIS 🌸

int srcu_read_lock_held (const struct srcu_struct *ssp );

🦋 ARGUMENTS 🦋

  • ssp — the srcu_struct structure you want to check, no cap 💅

🔥 DESCRIPTION 🔥

ok so here's the tea ☕ — if CONFIG_DEBUG_LOCK_ALLOC is selected, this returns nonzero iff you're in an SRCU read-side critical section. literally that simple. ✨

but if CONFIG_DEBUG_LOCK_ALLOC is not there? then it just goes ahead and assumes we're in an SRCU read-side critical section unless it can prove otherwise. optimistic queen energy, honestly 🫶

it also checks debug_lockdep_rcu_enabled to prevent false positives during boot and while lockdep is disabled. gotta stay accurate, y'know? 😌

💀 real talk though: note that SRCU is based on its own statemachine and it doesn't relies on normal RCU, so it can be called from the CPU which is in the idle loop from an RCU point of view or offline. iconic behaviour, honestly 👑

💜 SEE ALSO 💜

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

anyway that's the whole vibe 🌈 this one came straight out of ./include/linux, dated October 2026, and it's filed under srcu_read_lock_held(9). go off, kernel docs 👑💖

📦 where this page comes from