srcu_read_lock(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… srcu_read_lock β€” the kernel API manual, but make it make sense

okay so bestie, welcome to srcu_read_lock(9) β€” this is the Kernel API Manual page for the SRCU reader-registration function, and yes we're gonna get into it πŸ’–


✨ NAME ✨

srcu_read_lock β€” register a new reader for an SRCU-protected structure. that's it, that's the whole vibe. you're clocking in as a reader πŸ“–βœ¨


πŸŽ€ SYNOPSIS πŸŽ€

int srcu_read_lock (struct srcu_struct *ssp );

🌸 ARGUMENTS 🌸

  • ssp β€” the srcu_struct you're registering this shiny new reader into. this is the structure you're claiming reader status on, no cap 🫢

πŸ’… DESCRIPTION πŸ’…

so what this actually does: it enters an SRCU read-side critical section. you're in it now, bestie, main character energy, the section is yours πŸ’–

and lowkey the nice part β€” SRCU read-side critical sections may be nested. go ahead, stack 'em, we love a nestable situation ✨

⚠️ but here's the part where you don't get to be chaotic: it is illegal to call anything that waits on an SRCU grace period for the same srcu_struct, whether directly or indirectly. and yes, indirect counts β€” please note that one way to indirectly wait on an SRCU grace period is to acquire a mutex that is held elsewhere while calling synchronize_srcu or synchronize_srcu_expedited. so like… don't do that πŸ™ˆ that's a whole deadlock situation waiting to happen and not in a cute way πŸ’€

okay now the return value, this is important, pay attention πŸŽ€

The return value from srcu_read_lock is guaranteed to be non-negative. That value must be passed unaltered to the matching srcu_read_unlock. unaltered!! do not touch it, do not "improve" it, do not pass something adjacent β€” it goes in exactly as it came out, periodt πŸ‘‘

πŸ¦‹ and one more: srcu_read_lock and the matching srcu_read_unlock must occur in the same context. for example, it is illegal to invoke srcu_read_unlock in an irq handler if the matching srcu_read_lock was invoked in process context. or, for that matter, to invoke srcu_read_unlock from one task and the matching srcu_read_lock from another. the lock/unlock pair is a package deal, they stay together, fr fr 😭

πŸ”₯ SEE ALSO πŸ”₯

Kernel file ./include/linux/srcu.h β€” and like, the whole extended SRCU family reunion:


and that's the page, bestie πŸ§šπŸ’œ this iconic little number lives in ./include/linux, dated October 2026, and it's filed under srcu_read_lock(9). go forth and register your readers responsibly, mwah πŸ’‹πŸŒΈ

πŸ“¦ where this page comes from