trace_irq_handler_exit(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… trace_irq_handler_exit β€” the kernel API manual, bestie edition ✨

okay so you're looking at trace_irq_handler_exit(9) and you opened the manual page and honestly? iconic choice. this is the little tracepoint that fires right after an irq action handler comes back home. let's get into it 🫢


🌸 NAME 🌸

trace_irq_handler_exit β€” called immediately after the irq action handler returns, no cap πŸ’–


✨ SYNOPSIS ✨

void trace_irq_handler_exit (int irq , struct irqaction *action , int ret );

that's the whole signature, copy it exactly, do not get creative with the spacing, the kernel does not think that's funny πŸŽ€


πŸ¦‹ ARGUMENTS πŸ¦‹

  • irq β€” the irq number. just the number. that's her whole job πŸ’…
  • action β€” pointer to struct irqaction. a pointer, bestie, so handle with care 🌸
  • ret β€” the return value. this one is the main character, keep reading πŸ‘‘

πŸ”₯ DESCRIPTION πŸ”₯

so here's the tea β˜• if the ret value is set to IRQ_HANDLED, then we know the corresponding action->handler successfully handled this irq. slay. ate. no notes. ✨

but if it's not? then it could mean the irq is a shared irq line, or the irq just was not handled successfully. either way, that's the vibe check and it did not pass 😭

this is also lowkey the bestie of irq_handler_entry β€” pair the two together and you can understand irq handler latencies. two tracepoints, one story, fr fr 🫢

ngl this is a tracepoint page so there aren't any options or exit statuses to worry about here β€” it's all about the args and the ret value, periodt πŸ’œ

🌈 SEE ALSO 🌈

go read the kernel file ./include/trace/events/irq.h and then go be obsessed with the whole tracepoint friend group:


and that's the page, bestie πŸŽ€ it lives in the ./include/trace/events directory, it's dated October 2026, and it's filed under trace_irq_handler_exit(9) β€” go forth and trace those irqs, mwah πŸ’‹πŸ’–

πŸ“¦ where this page comes from