Understanding Linux Hard IRQ vs Soft IRQ: A Deep Dive into Kernel Interrupt Handling

In a discussion on the ChinaUnix forum, the author revisits the Linux kernel's interrupt handling mechanism—specifically the difference between hard IRQ and soft IRQ—building on the explanation found in Chapter 5 of *Linux Device Drivers* (ILDD). The focus is on x86 32‑bit systems.

Overall Interrupt Framework

The following diagram (from ILDD) shows the high‑level structure of interrupt processing.

preempt_count Layout

The second diagram illustrates how the kernel uses the preempt_count variable to identify the current interrupt context.

Hard IRQ Entry – do_IRQ and irq_enter

When an external interrupt occurs, the CPU disables further external interrupts before invoking do_IRQ. Inside do_IRQ, the call to irq_enter() marks the beginning of the hard‑IRQ phase by incrementing the HARDIRQ part of preempt_count. The ISR runs with interrupts still disabled (EFLAGS.IF = 0), so the kernel expects the ISR to finish quickly and defer lengthy work to the soft‑IRQ phase.

unsigned int __irq_entry do_IRQ(struct pt_regs *regs)
{
    ...
    irq_enter();
    // handle external interrupt (ISR)
    ...
    irq_exit();
    return 1;
}

Transition to Soft IRQ – irq_exit

The function irq_exit() decrements the HARDIRQ counter, clears the hard‑IRQ context, and, if the processor is not already in an interrupt and there are pending soft‑IRQs, calls invoke_softirq() to start soft‑IRQ processing.

void irq_exit(void)
{
    ...
    sub_preempt_count(IRQ_EXIT_OFFSET);
    if (!in_interrupt() && local_softirq_pending())
        invoke_softirq();
    rcu_irq_exit();
    ...
}

When Is the Processor in an Interrupt Context?

ILDD defines in_interrupt() as a check of preempt_count to determine whether the current code is executing in any interrupt context (HARDIRQ, SOFTIRQ, or NMI). Soft‑IRQ execution therefore depends on two conditions: the processor must not already be in an interrupt, and there must be pending soft‑IRQs.

Soft IRQ Core – __do_softirq

The core of soft‑IRQ handling resides in __do_softirq(). It retrieves the pending soft‑IRQ bitmap, marks entry into the soft‑IRQ context, enables external interrupts, and then iterates over each set bit, invoking the corresponding action function (e.g., tasklet handlers). After processing, it disables interrupts again, checks for newly pending soft‑IRQs, and may restart the loop.

asmlinkage void __do_softirq(void)
{
    ...
    pending = local_softirq_pending();
    __local_bh_disable((unsigned long)__builtin_return_address(0), SOFTIRQ_OFFSET);
    ...
    restart:
    set_softirq_pending(0);
    local_irq_enable();
    h = softirq_vec;
    do {
        if (pending & 1) {
            h->action(h);
        }
        h++;
        pending >>= 1;
    } while (pending);
    local_irq_disable();
    pending = local_softirq_pending();
    if (pending && --max_restart)
        goto restart;
    __local_bh_enable(SOFTIRQ_OFFSET);
}

Soft IRQ Mapping and Tasklets

The per‑CPU variable __softirq_pending uses bits 0‑9 to represent ten different soft‑IRQ types. For example, bit 0 corresponds to HI_SOFTIRQ whose action is tasklet_hi_action, analogous to the regular tasklet handler TASKLET_SOFTIRQ. The kernel schedules a tasklet by setting the appropriate bit via tasklet_schedule(). ILDD discusses tasklets in both Chapter 5 (soft‑IRQ mechanism) and Chapter 6 (deferred work).

In summary, the Linux kernel separates interrupt handling into a hard‑IRQ phase, where the ISR runs with interrupts disabled, and a soft‑IRQ phase, where the kernel re‑enables interrupts and processes deferred work in a controlled loop, using preempt_count to track context and prevent re‑entrancy.