rcu_barrier(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– rcu_barrier(9) β€” the Kernel API Manual glow-up πŸŽ€

Okay bestie, so you're in the Kernel API Manual, section 9, and the star of the show is rcu_barrier. Let's get into it ✨


🌸 NAME 🌸

rcu_barrier β€” wait until all in-flight call_rcu() callbacks complete. That's it, that's the whole vibe. 🫢


πŸ¦‹ SYNOPSIS πŸ¦‹

void rcu_barrier (void );

πŸŽ€ ARGUMENTS πŸŽ€

  • void β€” no arguments. Not one. Zero. Empty set, bestie. πŸ’…

✨ DESCRIPTION ✨

Okay so real talk, this is the part where you think it's a full "wait for a whole RCU grace period" situation, and it's not. Note that this primitive does not necessarily wait for an RCU grace period to complete. Like, at all. πŸ™ˆ

For example, if there are no RCU callbacks queued anywhere in the system, then rcu_barrier is within its rights to return immediately, without waiting for anything, much less an RCU grace period. Literally just yeets itself back to the caller. 😭 In fact, rcu_barrier will normally not result in any RCU grace periods beyond those that were already destined to be executed. So it's not out here creating extra grace periods for fun β€” it only piggybacks on the ones already on the calendar. πŸ—“οΈ

Also, quick heads up: in kernels built with CONFIG_RCU_LAZY=y, this function also hurries all pending lazy RCU callbacks. So the lazy ones get a little nudge. Not lazy anymore. Periodt. πŸ”₯

πŸ‘‘ SEE ALSO πŸ‘‘


And that's the whole page, bestie β€” courtesy of ./kernel/rcu, dated October 2026, filed under rcu_barrier(9). Go forth and barrier responsibly πŸ§šπŸ’œ

πŸ“¦ where this page comes from