How Linux Handles Interrupts: A Five‑Stage Deep Dive into Asynchronous Processing

While researching asynchronous message processing, the author recalled Linux kernel interrupt handling, which follows the principle “do important things immediately, defer the rest,” and organized the process into five stages.

First Stage: Getting the Interrupt Number

Each CPU can respond to interrupts using the same interrupt service routine (ISR). When the ISR is entered, the CPU automatically disables further interrupts on that CPU because the ISR is not re‑entrant. The ISR pushes the interrupt number and the current register state onto the stack, then calls do_IRQ.

Second Stage: Interrupt Serialization

Inside do_IRQ, the kernel serializes interrupts that occur on multiple CPUs. If the same interrupt is already in the “executing” state on another CPU, the kernel sets a “trigger” flag and returns immediately. After the first CPU finishes, it checks the flag and, if set, processes the interrupt again. This creates a loop where handle_IRQ_event is repeatedly called.

Third Stage: Handling with Interrupts Disabled

handle_IRQ_event

invokes the handler registered via request_irq. Handlers usually run with interrupts disabled; they can be enabled but only if the code is fully re‑entrant, which is rare. Long handlers that run with interrupts disabled block subsequent interrupts, so the kernel introduces softirqs: the non‑re‑entrant part is done in the ISR, then raise_softirq schedules a softirq and the ISR returns.

Fourth Stage: Softirq Processing with Interrupts Enabled

After the ISR loop, do_softirq processes pending softirqs. Each CPU maintains a bitmask of softirq numbers; the corresponding softirq handler (registered with open_softirq) is invoked. Softirqs are similar to interrupts but run with interrupts enabled, allowing nesting. Only the first‑level ISR reaches this stage; nested interrupts stop after the third stage. If many softirqs accumulate, the kernel offloads the remaining work to the ksoftirqd kernel thread.

Fifth Stage: Tasklet Processing with Interrupts Enabled

Tasklets are built on top of softirqs. The kernel defines two softirq masks, HI_SOFTIRQ and TASKLET_SOFTIRQ, each with its own handler. After the ISR finishes its disabled‑interrupt part, it calls tasklet_schedule or tasklet_hi_schedule to mark a tasklet. The tasklet’s handler runs in softirq context, is serialized across CPUs, and does not need to be re‑entrant.

Conclusion

After completing the five stages, the CPU restores the registers saved on the stack and exits the interrupt handling flow.

Scheduling Considerations

Interrupt handlers have no task structure, so they cannot be scheduled or put to sleep. This can cause low‑priority interrupts to occupy the CPU and prevents the use of sleeping functions (e.g., memory allocation) inside handlers. Newer kernels use ksoftirqd to defer excess softirq work to a kernel thread, though sleeping is still prohibited in the softirq context. Some real‑time Linux variants (e.g., MontaVista) attach a task structure to interrupt handlers, allowing them to be scheduled at the cost of overall performance.

Workqueues

The Linux kernel provides a workqueue mechanism to defer work to kernel threads that can sleep. A work structure containing a processing function is created, and schedule_work adds it to a workqueue. Worker threads process these works, allowing sleeping operations. The default workqueue spawns a set of threads (one per CPU) named events/n, and drivers can also create their own workqueues.