poll_state_synchronize_srcu(9)

📦 version 7.3.1, in nixpkgs unstable

poll_state_synchronize_srcu(9) 💅✨

okay so bestie, welcome to the poll_state_synchronize_srcu(9) page — that's the manual name right there, we're in the Kernel API Manual section, and honestly? this one's a little baddie about asking one very simple question. let's get into it 🎀

✨ NAME ✨

poll_state_synchronize_srcu — Has cookie's grace period ended? 🍪⏰

like literally that's the whole vibe check. does the cookie know it's free yet or not.

🌸 SYNOPSIS 🌸

bool poll_state_synchronize_srcu (struct srcu_struct *ssp , unsigned long cookie );

she returns a bool, she takes two things, and she does not elaborate further. iconic behavior honestly 💅

🦋 ARGUMENTS 🦋

  • ssp — the srcu_struct to provide cookie for. this is the one handing out the cookie in the first place, okay, she's the cookie source 🍪
  • cookie — Return value from get_state_synchronize_srcu or start_poll_synchronize_srcu. so like, you gotta already have a cookie from one of those two. don't just show up with a random cookie, bestie, that's not how this works 😭

💖 DESCRIPTION 💖

So the way this works: this function takes the cookie that was returned from either get_state_synchronize_srcu or start_poll_synchronize_srcu, and returns true if an SRCU grace period elapsed since the time that the cookie was created. that's it! that's the whole function! grace period over → true, grace period not over → not true. slay, honestly 🫶

⚠️ okay now the scary part, pay attention bestie — because cookies are finite in size, wrapping/overflow is possible. no cap. it's not a maybe-someday-far-away thing, it's a real thing you gotta keep in your head.

Let me break the math down for you because it's giving "actually kind of unhinged" 💀:

  • This is more pronounced on 32-bit systems where cookies are 32 bits, where in theory wrapping could happen in about 14 hours assuming 25-microsecond expedited SRCU grace periods. fourteen hours!! a single day of uptime and the cookie's already doing a little loop-de-loop 🌈
  • However, a more likely overflow lower bound is on the order of 24 days in the case of one-millisecond SRCU grace periods. okay that's more reasonable, still not forever though 🕰️
  • Of course, wrapping in a 64-bit system requires geologic timespans, as in more than seven million years even for expedited SRCU grace periods. seven. million. years. that cookie is gonna outlive the sun, fr fr ☀️👑

And here's the part that lowkey matters most for the weird configs:

Wrapping/overflow is much more of an issue for CONFIG_SMP=n systems that also have CONFIG_PREEMPTION=n, which selects Tiny SRCU. Tiny SRCU uses a 16-bit cookie, which rcutorture routinely wraps in a matter of a few minutes. minutes!! the cookie is practically speedrunning its own overflow, it's giving main character energy but make it chaotic 😭

If this proves to be a problem, this counter will be expanded to the same size as for Tree SRCU. so like, it's a known thing, there's a fix on the table, don't panic 🧚

💜 SEE ALSO 💜

Kernel file ./kernel/rcu/srcutree.c, plus the whole friend group:

go read get_state_synchronize_srcu(9) and start_poll_synchronize_srcu(9) first bestie, you literally cannot use this page without them 💖

aaaand that's the page! 🌟 this cutie lives in ./kernel/rcu, it's dated October 2026, and its manual name is poll_state_synchronize_srcu(9) — remember it fondly, hydrate, and go check your cookies 🍓💅

📦 where this page comes from