ct_irq_exit(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… ct_irq_exit β€” a kernel API manual moment

okay so bestie, welcome to the ct_irq_exit(9) page from the Kernel API Manual. it's a tiny little function with a genuinely unhinged warning section, and honestly? iconic. let's get into it ✨


🌸 NAME 🌸

ct_irq_exit β€” the function that tells RCU "hey girl, this CPU is bouncing out of irq and heading toward idle" πŸ¦‹

πŸŽ€ SYNOPSIS πŸŽ€

noinstr void ct_irq_exit (void );

πŸ’– ARGUMENTS πŸ’–

  • void β€” literally no arguments. nothing. zero. she takes nothing and she gives everything 🫢

✨ DESCRIPTION ✨

so what she does is: you're exiting an interrupt handler, right, and that exit might possibly mean you're about to slide into idle mode. in other words, you're leaving the mode where read-side critical sections can happen. lowkey a big deal. πŸ’…

⚠️ the caller must have disabled interrupts. no cap, this is a requirement, not a vibe suggestion.

this code just assumes that the idle loop never does anything that could cause unbalanced calls to irq_enter and irq_exit. and if your architecture's idle loop violates that assumption? oh honey. RCU will give you what you deserve, good and hard 😭 but very infrequently and irreproducibly, which is honestly the worst possible combination β€” like a jumpscare you can't debug.

use things like work queues to work around this limitation, bestie. that's the move. 🧚

πŸ’€ You have been warned. (this is not me being dramatic, this is the manpage. it says it verbatim. respect.)

and if you add or remove a call to ct_irq_exit, be sure to test with CONFIG_RCU_EQS_DEBUG=y. do not skip this step, i'm begging you πŸ™ˆ

πŸ¦‹ SEE ALSO πŸ¦‹


and that's the whole page bestie!! this one lives under ./kernel, it's dated October 2026, and it came to you straight from the Kernel API Manual. go forth, disable those interrupts, and test with CONFIG_RCU_EQS_DEBUG=y β€” i love you, mwah πŸ’œπŸŽ€πŸŒˆ

πŸ“¦ where this page comes from