rcu_access_pointer(9)

📦 version 7.3.1, in nixpkgs unstable

💅 rcu_access_pointer — the "look but don't touch" of RCU pointers ✨

hey bestie, welcome to the rcu_access_pointer(9) page from the Kernel API Manual 🎀 this one's short but she has opinions, okay? like, there are right ways and wrong ways to use her and the manpage is very much going to tell you about both 🫶

✨ SYNOPSIS ✨

rcu_access_pointer (p );

🌸 ARGUMENTS 🌸

  • p — the pointer you wanna read, bestie. that's it. that's the argument 💖

🦋 DESCRIPTION 🦋

okay so, what does she actually do? she returns the value of the specified RCU-protected pointer, but — and this is the iconique part — she omits the lockdep checks for being in an RCU read-side critical section 💅 no cap, that's the whole vibe.

when is that useful? when you're accessing the value of the pointer but not dereferencing it — for example, when you're testing an RCU-protected pointer against NULL. that's her moment, that's her main character energy ⭐

lowkey: if you're already inside an RCU read-side critical section, there's little reason to use rcu_access_pointer. like, just use the normal one, queen 😭

she can also be used in cases where update-side locks prevent the value of the pointer from changing — but ngl, you should use rcu_dereference_protected for that use case instead. she said what she said 🙈

it's also permissible to use rcu_access_pointer within lockless updaters to obtain the old value for an atomic operation — for example, for cmpxchg. slay 🔥

💀 the "accident waiting to happen" section (yes really) 💀

it is usually best to test the rcu_access_pointer return value directly, okay? the whole point is to avoid accidental dereferences being introduced by later inattentive changes. in other words:

assigning the rcu_access_pointer return value to a local variable results in an accident waiting to happen. 😭😭😭

like. don't do it. she's literally warning you. this is the "not me leaving a footgun in my own code" moment, fr fr 💀

🧚 the grace-period use case 🧚

it is also permissible to use rcu_access_pointer when read-side access to the pointer was removed at least one grace period ago — as is the case in the context of the RCU callback that is freeing up the data, or after a synchronize_rcu returns ✨

this can be useful when tearing down multi-linked structures after a grace period has elapsed 🫶

however (and she's very clear about this): rcu_dereference_protected is normally preferred for this use case too. it's giving "she'll let you, but she'd rather you didn't" 💅

🌈 SEE ALSO 🌈

the girlies she runs with — so many icons, honestly 👑 kernel file ./include/linux/rcupdate.h, plus:

okay that's the whole page bestie, you ate that 💖 mwah 🫶

this one comes to you from ./include/linux, dated October 2026, and it's literally titled rcu_access_pointer(9) — go forth and don't assign her return value to a local variable, i'm begging 😭🌸💜

📦 where this page comes from