rcu_assign_pointer(9)

📦 version 7.3.1, in nixpkgs unstable

💅 rcu_assign_pointer(9) — the kernel API manual, bestie edition

okay so you opened the rcu_assign_pointer page from the Kernel API Manual and you want the tea. say less, i got you 🫶

✨ NAME ✨

rcu_assign_pointer — assign to RCU-protected pointer. that's the whole vibe. it's giving "publishing pointers safely" and honestly? iconic.

🌸 SYNOPSIS 🌸

rcu_assign_pointer (p , v );

yes bestie, the spacing is weird, that's just how the manpage renders it, we do not touch it 💀

🎀 ARGUMENTS 🎀

  • p — pointer to assign to. like, the destination. the address that's about to get a whole new personality.
  • v — value to assign (publish). this is the thing you're making visible to the world. publish it, queen 👑

🦋 DESCRIPTION 🦋

so what does it actually do. it assigns the specified value to the specified RCU-protected pointer, and it does it in a way that ensures any concurrent RCU readers will see any prior initialization. no cap, that's the whole point — nobody sees a half-built struct, everyone sees the finished glow-up ✨

it inserts memory barriers on architectures that require them (which is most of them, fr fr), and it also prevents the compiler from reordering the code that initializes the structure after the pointer assignment. compiler said "i'll just move this around a little" and this macro said "absolutely not, sit down 💅".

but more importantly — and this is the part that's lowkey the whole reason it exists — this call documents which pointers will be dereferenced by RCU read-side code. it's like a lil name tag for your pointer. iykyk.

🚨 okay now the serious part, bestie. in some special cases, you may use RCU_INIT_POINTER instead of rcu_assign_pointer. RCU_INIT_POINTER is a bit faster due to the fact that it does not constrain either the CPU or the compiler. sounds cute right? it is NOT cute if you use it wrong.

that said, using RCU_INIT_POINTER when you should have used rcu_assign_pointer is a very bad thing that results in impossible-to-diagnose memory corruption. like, memory corruption that will find you at 3am and you will have zero clues. so please be careful 🙈 see the RCU_INIT_POINTER comment header for details.

also — and this is the sneaky lil detail that ate — note that rcu_assign_pointer evaluates each of its arguments only once, appearances notwithstanding. one of the "extra" evaluations is in typeof and the other visible only to sparse (__CHECKER__), neither of which actually execute the argument. so the extra ones are basically set dressing, they don't do anything 🔥

as with most cpp macros, this execute-arguments-only-once property is important, so please be careful when making changes to rcu_assign_pointer and the other macros that it invokes. like, don't be out here breaking the once-only guarantee, that's main character behavior in the worst way 😭

💜 SEE ALSO 💜

kernel file ./include/linux/rcupdate.h — and then the whole extended friend group, in order, bestie:

and that's the page, bestie 🌈 this lil masterpiece lives in ./include/linux, dated October 2026, and it's filed under rcu_assign_pointer(9). go publish a pointer responsibly, ily, mwah 💖🧚

📦 where this page comes from