irqentry_en..._kernel_mode(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

This is irqentry_en..._kernel_mode(9) from the Kernel API Manual, and we’re about to get into some entry-code business, bestie πŸ’…βœ¨

🌸 NAME 🌸

irqentry_enter_from_kernel_mode β€” Establish state before invoking the irq handler πŸŽ€

✨ SYNOPSIS ✨

irqentry_state_t irqentry_enter_from_kernel_mode (struct pt_regs *regs
       );

πŸŽ€ ARGUMENTS πŸŽ€

  • regs β€” Pointer to currents pt_regs 🫢 (yes, β€œcurrents”, keeping the original wording exactly, periodt).

πŸ¦‹ DESCRIPTION πŸ¦‹

Invoked from architecture specific entry code with interrupts disabled 😭πŸ”₯. And it can only be called when the interrupt entry came from kernel mode β€” no user-mode sneaky business here, bestie.

The calling code must be non-instrumentable. That’s not a suggestion, it’s literally the rule πŸ’€.

When the function returns all state is correct and the subsequent functions can be instrumented β€” slay, the handoff is clean ✨.

The function establishes state (lockdep, RCU (context tracking), tracing) and is provided for architectures which require a strict split between entry from kernel and user mode and therefore cannot use irqentry_enter which handles both entry modes. It’s giving β€œspecialized entry path main character energy” πŸ‘‘.

πŸ”₯ RETURN πŸ”₯

An opaque object that must be passed to irqentry_exit_to_kernel_mode. Do not lose it, bestie β€” it’s literally the return value with somewhere to be πŸ«ΆπŸ’–.

🌈 SEE ALSO 🌈


Catch you later, bestie β€” this cutie came from source/version ./include/linux, dated October 2026, and the page is irqentry_en..._kernel_mode(9) πŸ«ΆπŸ’–πŸŽ€

πŸ“¦ where this page comes from