← Interview Prep

Linux Kernel — Interrupts & Exceptions

Servicing hardware and CPU events: the IDT & vectors (APIC/MSI-X/IPIs), interrupt vs fault vs trap vs abort, top-half/bottom-half split (softirq/tasklet/workqueue — which can sleep), NAPI, the can't-sleep rule, spin_lock_irqsave, and IRQ affinity.

How the CPU stops what it's doing to service hardware and CPU-detected events — and how Linux keeps interrupt handlers fast so the system stays responsive. Original, interview-focused notes.

Two families: an interrupt is asynchronous, raised by a device (a NIC has a packet); an exception is synchronous, raised by the CPU while executing an instruction (page fault, divide-by-zero, a syscall/trap). Both vector through the IDT to a handler that runs in a special context where you cannot sleep.

The dispatch: IDT & vectors

• The Interrupt Descriptor Table maps each of 256 vectors to a handler. Low vectors are CPU exceptions (0 = divide error, 14 = page fault…); higher ones are device IRQs and IPIs.
• Modern delivery uses the APIC (local + I/O APIC) and MSI/MSI-X — devices signal interrupts by writing a memory address, so no shared IRQ lines and many vectors per device (one per NIC queue).
• IPIs (inter-processor interrupts) let CPUs signal each other — e.g. TLB shootdowns, reschedule.

Exceptions vs interrupts vs traps

Top half & bottom half

An interrupt handler must be fast — while it runs, that interrupt (often more) is masked and no process runs on the CPU. So Linux splits the work:

• Top half (the hard IRQ handler): do the minimum — acknowledge the device, grab the data, note that work is pending — then return. Runs in interrupt context: no sleeping, no blocking locks, no copy_to_user.
• Bottom half: the deferred, heavier work, run later with interrupts enabled:

NAPI is the classic example: under load the NIC switches from per-packet interrupts to polling in softirq, avoiding an interrupt storm. ksoftirqd drains softirqs when they overwhelm a CPU.

The "can't sleep" rule & concurrency

• In interrupt/softirq context there's no backing process to schedule, so blocking would deadlock the CPU — hence no mutexes/sleeping, only spinlocks (and the IRQ-safe spin_lock_irqsave variant when sharing data with a handler).
• Local interrupts can be masked (local_irq_save) to protect data touched by both a handler and normal code; keep these windows tiny — masking hurts latency.
• Affinity: /proc/irq/<n>/smp_affinity pins an IRQ to CPUs; spreading NIC-queue interrupts across cores (RSS) is core to high-throughput and low-latency tuning. See Linux Basics.