rcu_read_lock(9)

💖 rcu_read_lock(9) 💖

okay so this is a page from the Kernel API Manual, and it's about rcu_read_lock — the function that literally just says "hey, I'm starting an RCU read-side critical section now, bestie." Buckle up, this one's a whole personality. 🎀

---

✨ NAME ✨

rcu_read_lock — marks the beginning of an RCU read-side critical section, periodt.

---

✨ SYNOPSIS ✨

void rcu_read_lock (void );

---

✨ ARGUMENTS ✨

• void — literally no arguments. she takes nothing, she gives everything 💅

---

✨ DESCRIPTION ✨

okay so first thing's first: when synchronize_rcu gets invoked on one CPU while other CPUs are chilling inside RCU read-side critical sections, then that synchronize_rcu is guaranteed to block until after all those other CPUs exit their critical sections. no cap, that's the whole deal.

same energy with call_rcu — if you invoke it on one CPU while other CPUs are inside RCU read-side critical sections, then the invocation of the corresponding RCU callback gets deferred until after all the other CPUs exit their critical sections. it's giving "wait your turn" energy. 🦋

and plot twist: both synchronize_rcu and call_rcu also wait for regions of code with preemption disabled — including regions of code with interrupts or softirqs disabled. so like, respect the whole no-preempt zone, iykyk.

but bestie, listen 👀 — RCU callbacks are permitted to run concurrently with new RCU read-side critical sections. that's legal and everything, don't panic.

one way this can happen is this iconic little sequence:

1. CPU 0 enters an RCU read-side critical section
2. CPU 1 invokes call_rcu to register an RCU callback
3. CPU 0 exits the RCU read-side critical section
4. CPU 2 enters a RCU read-side critical section
5. the RCU callback is invoked

and this is completely legal because the RCU read-side critical section that was running concurrently with the call_rcu (and which therefore might be referencing something that the corresponding RCU callback would free up) has completed before the corresponding RCU callback is invoked. slay, no use-after-free today. 🔥

---

RCU read-side critical sections may be nested. any deferred actions will be deferred until the outermost RCU read-side critical section completes. so like, nesting is allowed, just don't get weird about it. 🪆

---

okay so you can literally skip reading and understanding the next paragraph by following this one rule:

don't put anything in an rcu_read_lock RCU read-side critical section that would block in a !PREEMPTION kernel.

that's it. that's the rule. 🫶

but if you want the full story… read on! 🌈

• in non-preemptible RCU implementations (pure TREE_RCU and TINY_RCU), it is illegal to block while in an RCU read-side critical section. like, genuinely not allowed.
• in preemptible RCU implementations (PREEMPT_RCU) in CONFIG_PREEMPTION kernel builds, RCU read-side critical sections may be preempted, but explicit blocking is illegal. so preemption = yes, blocking = absolutely not 💀
• finally, in preemptible RCU implementations in real-time (with -rt patchset) kernel builds, RCU read-side critical sections may be preempted and they may also block — but only when acquiring spinlocks that are subject to priority inheritance. that's the one exception, bestie, don't run with it. 🙈

---

✨ SEE ALSO ✨

Kernel file ./include/linux/rcupdate.h → same_state_synchronize_rcu(9), cond_resched_tasks_rcu_qs(9), rcu_softirq_qs_periodic(9), RCU_LOCKDEP_WARN(9), lockdep_assert_in_rcu_read_lock(9), lockdep_assert_in_rcu_read_lock_bh(9), lockdep_assert_in_rcu_read_lock_sched(9), lockdep_assert_in_rcu_reader(9), unrcu_pointer(9), RCU_INITIALIZER(9), rcu_assign_pointer(9), rcu_replace_pointer(9), rcu_access_pointer(9), rcu_dereference_check(9), rcu_dereference_bh_check(9), rcu_dereference_sched_check(9), rcu_dereference_all_check(9), rcu_dereference_protected(9), rcu_dereference(9), rcu_dereference_bh(9), rcu_dereference_sched(9), rcu_dereference_all(9), rcu_pointer_handoff(9), rcu_read_unlock(9), rcu_read_lock_bh(9), rcu_read_unlock_bh(9), rcu_read_lock_sched(9), rcu_read_unlock_sched(9), RCU_INIT_POINTER(9), RCU_POINTER_INITIALIZER(9), kfree_rcu(9), kfree_rcu_mightsleep(9), kfree_rcu_nolock(9), rcu_head_init(9), rcu_head_after_call_rcu(9)

---

and that's the whole page, bestie — go forth and lock your reads 💜

this iconic piece of documentation lives in ./include/linux, dropped October 2026, and it's filed under rcu_read_lock(9). mwah 💋 ✨