get_state_sy...ize_rcu_full(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ NAME ✨

get_state_synchronize_rcu_full β€” bestie, this one takes a snapshot of the RCU state, and it does it for both the normal and the expedited flavors πŸ’…

(it's a Kernel API Manual situation, in case you were wondering where all this kernel lore is coming from 🫢)


🌸 SYNOPSIS 🌸

void get_state_synchronize_rcu_full (struct rcu_gp_seq *gsp );

πŸŽ€ ARGUMENTS πŸŽ€

  • gsp β€” the spot where you want the combined normal/expedited grace-period state to live. literally just hand it a place to put the goods πŸ“

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so boom: this function places the normal and the expedited grace-period states into gsp. two states, one struct, no cap ✨

That state value can then be passed to a later call to cond_synchronize_rcu_full or poll_state_synchronize_rcu_full to figure out whether or not a grace period has elapsed in the meantime β€” and yes, that's whether it's a normal grace period or an expedited one πŸ‘‘

Here's the tea on the rcu_gp_seq structure though: it takes up twice the memory of an unsigned long, but it is guaranteed to see all grace periods. iconic behavior, honestly. In contrast, the combined state occupies less memory, but can sometimes fail to take grace periods into account πŸ™ˆ so like… pick your fighter, iykyk.

⚠️ Important vibe check: this does not guarantee that the needed grace period will actually start. like, it's giving "I put in the request" not "the request is happening." periodt πŸ’€

πŸ‘‘ SEE ALSO πŸ‘‘

Kernel file ./kernel/rcu/tree.c


and that's the whole page, bestie!! 🌈 it lives over in ./kernel/rcu, dated October 2026 β€” mwah, go read some RCU docs, ily πŸ’–πŸ§š

πŸ“¦ where this page comes from