Linux 内核 Softirq 深度解析:从 pending 位图到 ksoftirqd 的全流程

网卡收到一个包，硬中断 handler 只做了最紧急的事：把数据从网卡的 DMA 缓冲区拷出来，然后 raise 一个 NET_RX softirq 就退出了。数据包完整处理全部发生在 softirq 上下文。这篇文章说清楚 softirq 是怎么被触发、怎么被执行、为什么它比硬中断危险得多。

硬中断 handler 为什么不能干完所有活

假设网卡 RX handler 上来就读 socket buffer、做协议栈解析、最后把数据扔给应用层——会发生什么？

整个系统被这个 handler 卡住，其他硬件中断进不来，调度器也被关在外面。如果 handler 里面不小心调了 copy_to_user() 等待磁盘 IO，整个机器就这么僵在那。

所以 Linux 内核的套路是：硬中断 handler 只做最紧急的事，然后把剩下的活扔给 softirq。硬中断退出的时候顺手检查一下有没有 pending 的 softirq，有就执行。整体思路和 tasklet 那篇文章说的一样，只是 softirq 在更底层。

固定10个槽位，编译期定死

softirq 的基础设施在 kernel/softirq.c 里就一行：

static struct softirq_action softirq_vec[NR_SOFTIRQS] __cacheline_aligned_in_smp;

NR_SOFTIRQS 是 10，这个值在内核头文件里写死，编译完之后就不能改了。每个槽位本质上是一个函数指针：

struct softirq_action {
   void    (*action)(struct softirq_action *);
};

一共有哪些 softirq，内核启动时注册：

const char *const softirq_to_name[NR_SOFTIRQS] = {
   "HI","TIMER","NET_TX","NET_RX","BLOCK","IRQ_POLL",
   "TASKLET","SCHED","HRTIMER","RCU"
};

NET_RX 处理网卡收包，NET_TX 处理网卡发包，TASKLET 本身也是一个 softirq（后文细说），TIMER/HRTIMER/RCU 各有各的用途。这个列表是内核代码里写死的，不存在驱动动态注册新的 softirq 类型这一说——驱动只能用已有的槽位，或者用 TASKLET softirq 自己实现 tasklet。

触发：设置一个 per-CPU 的 pending 位

每颗 CPU 有一个 per-CPU 的 pending 位图，记录"有哪些 softirq 需要执行"。在 include/linux/interrupt.h 里：

#define local_softirq_pending()   (__this_cpu_read(local_softirq_pending_ref))
#define set_softirq_pending(x)    (__this_cpu_write(local_softirq_pending_ref, (x)))
#define or_softirq_pending(x)     (__this_cpu_or(local_softirq_pending_ref, (x)))

local_softirq_pending_ref 实际上是 irq_stat 这个 per-CPU 变量里的 __softirq_pending 字段。用 per-CPU 变量是因为它完全无锁——每个 CPU 只读写自己的 pending 位，不存在竞争。

驱动要触发一个 softirq，调用 raise_softirq_irqoff（必须在关中断状态下调用）：

inline void raise_softirq_irqoff (unsigned int nr)
{
    __raise_softirq_irqoff(nr);

   if (!in_interrupt() && should_wake_ksoftirqd())
        wakeup_softirqd();
}

void __raise_softirq_irqoff(unsigned int nr)
{
    lockdep_assert_irqs_disabled();
    trace_softirq_raise(nr);
    or_softirq_pending(1UL << nr);  // 把第 nr 位设置为1
}

raise_softirq 干的事情就一件：把对应位设置为1。__raise_softirq_irqoff 名字里的 irqoff 不是说"关闭了 IRQ"，而是"调用者已经关闭了 IRQ"，所以这个函数本身不再做锁保护，直接 or 操作就行。

触发路径从硬中断 handler 出来是这样的：

执行：__do_softirq 主循环

pending 位设置好之后，什么时候执行？正常情况下在 irq_exit() 里：

static inline void __irq_exit_rcu(void)
{
#ifndef __ARCH_IRQ_EXIT_IRQS_DISABLED
    local_irq_disable();
#endif
    account_hardirq_exit(current);
    preempt_count_sub(HARDIRQ_OFFSET);
   if (!in_interrupt() && local_softirq_pending())
        invoke_softirq();
    tick_irq_exit();
}

条件是：不在中断上下文（!in_interrupt），且有待执行的 softirq（local_softirq_pending() 非0）。满足就 invoke_softirq()，在非 RT 内核上直接 __do_softirq() 或 __do_softirq_own_stack()。

__do_softirq() 的核心逻辑在 kernel/softirq.c 里：

asmlinkage __visiblevoid __softirq_entry __do_softirq(void)
{
   unsigned long end = jiffies + MAX_SOFTIRQ_TIME; // 2ms超时
   unsigned long old_flags = current->flags;
   int max_restart = MAX_SOFTIRQ_RESTART;           // 最多重启10次
   struct softirq_action *h;
    __u32 pending;
   int softirq_bit;

    pending = local_softirq_pending();  // 读 pending 位图

    softirq_handle_begin();              // preempt_count += SOFTIRQ_OFFSET
    in_hardirq = lockdep_softirq_start();
    account_softirq_enter(current);

restart:
    set_softirq_pending(0);             // 清空 pending 位
    local_irq_enable();                  // 开中断，允许嵌套

    h = softirq_vec;

   while ((softirq_bit = ffs(pending))) {  // ffs: 找最低位1
        h += softirq_bit -1;               // 定位到对应的 softirq_vec 项
        vec_nr = h - softirq_vec;
        prev_count = preempt_count();

        trace_softirq_entry(vec_nr);
        h->action(h);                       // 调用 handler
        trace_softirq_exit(vec_nr);

       if (unlikely(prev_count != preempt_count())) {
            pr_err("entered softirq %u with preempt_count %08x, exited with %08x\n",
                   vec_nr, prev_count, preempt_count());
            preempt_count_set(prev_count);   // 检测到抢占计数被破坏，直接修复
        }
        h++;
        pending >>= softirq_bit;             // 右移，清掉已处理的那位
    }

    local_irq_disable();

    pending = local_softirq_pending();
   if (pending) {
       if (time_before(jiffies, end) && !need_resched() && --max_restart)
           goto restart;
        wakeup_softirqd();                   // 超时或需要调度，退给 ksoftirqd
    }

    account_softirq_exit(current);
    lockdep_softirq_end(in_hardirq);
    softirq_handle_end();
}

几个关键细节：

ffs() 而不是逐位遍历。ffs(pending) 找到最低位为1的位置，直接跳到对应 handler，不用逐个判断。pending >>= softirq_bit 把已处理的那位清掉，然后继续循环处理下一位。

先清 pending 再开中断。set_softirq_pending(0) 在 local_irq_enable() 之前，这样如果 handler 执行期间同一个 CPU 又 raise 了 softirq，新的 pending 位会被保留，下次循环或下次进入时继续处理。

2ms 超时 + 10次重启上限。MAX_SOFTIRQ_TIME 是 2ms，MAX_SOFTIRQ_RESTART 是 10。超过任一限制就 wakeup_softirqd()，把剩余的活扔给内核线程处理，防止 softirq 霸占 CPU 导致系统无响应。

__do_softirq() 执行流程图：

ksoftirqd：最后的保险

如果 softirq 处理时间太长（超过2ms），或者调度器认为应该让出 CPU（need_resched()），__do_softirq() 会调用 wakeup_softirqd()，把剩余的活扔给 per-CPU 内核线程 ksoftirqd。

ksoftirqd 是一个死循环内核线程：

static int ksoftirqd_should_run (unsigned int cpu)
{
   return local_softirq_pending();
}

static void run_ksoftirqd (unsigned int cpu)
{
    local_irq_disable();
   if (local_softirq_pending()) {
        __do_softirq();
    }
    local_irq_enable();
}

醒来之后检查有没有 pending 的 softirq，有就执行。执行完后再次进入 schedule() 睡眠，等下次被唤醒。ksoftirqd 的存在保证了：即使 softirq 处理量太大，也不会把用户态进程饿死——调度器可以抢占它。

为什么 softirq 比硬中断更危险

栈空间极小

__do_softirq() 是在硬中断栈上跑的，不是普通进程栈。x86 上硬中断栈通常只有 8KB 或者 4KB，比普通进程栈小得多。如果 softirq handler 里的函数调用链太深，或者局部变量太大，直接爆栈。

对比一下：硬中断 handler 本身栈空间就紧张，softirq handler 是在这个紧张空间里继续挖。

preempt_count 被篡改检测

看 __do_softirq() 里这段：

if (unlikely(prev_count != preempt_count())) {
    pr_err("entered softirq %u with preempt_count %08x, exited with %08x\n",
           vec_nr, prev_count, prev_count, preempt_count());
    preempt_count_set(prev_count);
}

handler 执行前后 preempt_count 必须一致。如果不一致，说明 handler 内部有什么地方悄悄关闭了抢占或者改变了计数——这是一个严重的 bug，内核直接打印错误并强修。

为什么这个检测有意义？因为 softirq 执行时 preempt_count 里有 SOFTIRQ_OFFSET 位段，这个位段标识"当前在 softirq 上下文"。如果 handler 里不小心做了 schedule()，内核调度器会认为还在 softirq 里，可能产生不可预期的行为。

同一个 softirq 类型可以多 CPU 并发

这是和 tasklet 最大的区别。看 softirq_vec[NR_SOFTIRQS] 是全局的，一个 NET_RX softirq handler 在 CPU0 执行的同时，CPU1 也可以执行同一个 handler。如果驱动在 handler 里用了全局共享变量没加锁，各种 race 条件等着你。

而 tasklet 跑在 TASKLET_SOFTIRQ 上，但 tasklet_action() 会从 per-CPU 链表取任务，同一个 tasklet 实例不会在多 CPU 上同时跑——这是 tasklet 比 raw softirq 安全的地方。

softirq 和 tasklet 的关系

tasklet 是构建在 softirq 上的一个子机制。内核在启动时注册：

open_softirq(TASKLET_SOFTIRQ, tasklet_action);
open_softirq(HI_SOFTIRQ, tasklet_hi_action);

tasklet_action() 是通用的 tasklet 处理函数，它从 per-CPU 链表里取所有 pending 的 tasklet，挨个执行 callback。每个 tasklet 实例是链表节点，挂在某个 CPU 的链表上，同一时刻只被一个 CPU 处理——这层串行化是 tasklet 机制自己保证的，不需要驱动操心。

所以 softirq 是地基，tasklet 是地基上盖的房子。内核自己的网络协议栈直接用 softirq（NET_TX/NET_RX），追求极致性能；普通驱动用 tasklet，够用且安全。

总结

softirq 是内核最底层的中断下半部机制：硬中断退出后检查 per-CPU pending 位图，ffs() 遍历找到待处理的 softirq，调用对应 handler 执行。每个 handler 执行时间有限制（2ms），超时就踢给 ksoftirqd 处理。

它比硬中断危险是因为栈空间更小、可以多 CPU 并发、对 preempt_count 有严格要求。内核自己用 softirq 追求性能，普通驱动用 tasklet 追求安全——搞清楚这层关系，用什么、什么时候用，心里就有底了。