Linux内核Softlockup检测架构差异及死循环触发原理问询

场景与问题概述 #

我在QEMU环境中使用原生Linux v6.5内核，编写了一个触发软锁死的内核模块，代码如下：

static int __init soft_lockup_init(void) {
    printk(KERN_INFO "Soft lockup module loaded\n");

    // 无限循环触发softlockup
    while (1) {
        // 防止编译器优化掉循环
        barrier();
    }

    return 0;
}

内核已开启CONFIG_SOFTLOCKUP_DETECTOR=y和CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y配置。

架构差异现象 #

• x86_64架构：加载模块后系统触发panic，符合预期：

  watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [insmod:102]
  

  调用栈：

  [   60.972181] Call Trace:
  [   60.972181]  <IRQ>
  [   60.972181]  ? watchdog_timer_fn+0x1ad/0x210
  [   60.972181]  ? __pfx_watchdog_timer_fn+0x10/0x10
  [   60.972181]  ? __hrtimer_run_queues+0x125/0x2d0
  [   60.972181]  ? hrtimer_interrupt+0xfb/0x240
  [   60.972181]  ? __sysvec_apic_timer_interrupt+0x5e/0x130
  [   60.972181]  ? sysvec_apic_timer_interrupt+0x69/0x90
  [   60.972181]  </IRQ>
  

• AArch64架构：加载同一模块后，无论等待多久都无法触发softlockup，但硬锁死（hardlockup）检测器在两种架构上均正常工作。由于softlockup和hardlockup检测器共用watchdog_time_fn()，理论上应在AArch64上正常工作，这是否属于内核bug？

第二个疑问：module_init死循环为何触发softlockup？ #

我原本认为这段代码可以被抢占，其他任务仍能使用运行insmod的CPU核心，但实际却触发了softlockup，这个理解是否错误？

补充调试信息 #

通过GDB连接QEMU实例后的观察：

• x86_64：加载模块后，处理insmod请求的核心永久卡在死循环中，栈回溯可证明：

  >>> bt
  #0  0xffffffffc0006020 in ?? ()
  #1  0xffffffff81001a33 in do_one_initcall (fn=0xffffffffc0006010) at init/main.c:1232
  #2  0xffffffff8112a03f in do_init_module (mod=0xffffffffc0002040) at kernel/module/main.c:2530
  #3  0xffffffff8112c07b in load_module (info=0xffffffff8200148a <asm_sysvec_apic_timer_interrupt+26>, info@entry=0xffffc900001fbde8, uargs=0x0 <fixed_percpu_data>, uargs@entry=0x55c5e26e72a0 "", flags=17617392, flags@entry=0) at kernel/module/main.c:2981
  #4  0xffffffff8112c556 in init_module_from_file (f=f@entry=0xffff88810143b300, uargs=uargs@entry=0x55c5e26e72a0 "", flags=flags@entry=0) at kernel/module/main.c:3148
  #5  0xffffffff8112c72c in idempotent_init_module (f=f@entry=0xffff88810143b300, uargs=uargs@entry=0x55c5e26e72a0 "", flags=flags@entry=0) at kernel/module/main.c:3165
  #6  0xffffffff8112c8a6 in __do_sys_finit_module (flags=0, uargs=0x55c5e26e72a0 "", fd=<optimized out>) at kernel/module/main.c:3186
  #7  __se_sys_finit_module (flags=0, uargs=94308395807392, fd=<optimized out>) at kernel/module/main.c:3169
  #8  __x64_sys_finit_module (regs=<optimized out>) at kernel/module/main.c:3169
  #9  0xffffffff81eacf4f in do_syscall_x64 (nr=<optimized out>, regs=0xffffc900001fbf58) at arch/x86/entry/common.c:50
  #10 do_syscall_64 (regs=0xffffc900001fbf58, nr=<optimized out>) at arch/x86/entry/common.c:80
  #11 0xffffffff820000ea in entry_SYSCALL_64 () at arch/x86/entry/entry_64.S:120
  #12 0x00007f1cc46ff000 in ?? ()
  #13 0x00007ffe84e5a590 in ?? ()
  #14 0x00007f1cc46feac0 in ?? ()
  #15 0x00007ffe84e5af56 in ?? ()
  #16 0x0000000000000003 in fixed_percpu_data ()
  #17 0x000055c5e26e72a0 in ?? ()
  #18 0x0000000000000246 in ?? ()
  #19 0x0000000000000000 in ?? ()
  

  完全符合softlockup触发条件。
• AArch64：所有核心会定期执行softlockup_fn()，从而避免了softlockup检测。这是否意味着do_init_module()在两种架构上的行为存在差异？

内容的提问来源于stack exchange，提问作者InsaneCoder