ARM双核环境下spin_lock引发Soft Lockup问题咨询

问题本质分析 #

1. 调度上下文特性冲突

   • Tasklet属于软中断上下文，绑定到触发它的CPU（此处为CPU0）执行，优先级高于进程上下文（workqueue的kworker属于进程上下文），且同CPU上的软中断上下文不会被进程上下文抢占。
   • Spin_lock在SMP环境下拿不到锁时会进入忙等循环（不会主动让出CPU），而workqueue的kworker在CPU0上执行时，一旦开始忙等锁，就会被高优先级的tasklet抢占CPU，但tasklet本身又在频繁访问同一把锁，导致kworker完全没有机会获取锁，持续忙等超过watchdog阈值（22s），触发soft lockup。

2. 栈信息的验证匹配
   栈信息显示kworker卡在_raw_spin_lock，调用链指向workqueue的my_work_fn→destFind；同时tasklet的调用链是mymodule_tasklet_handler→initPacket_intasklet→destFind，说明两者确实在同一CPU上竞争同一把spin_lock，完全符合上述死循环场景。

3. “频繁加解锁”是触发条件而非直接原因
   哪怕tasklet不是频繁加解锁，只要它持续占用CPU0的软中断时间（比如处理大量数据包时反复被触发），而workqueue刚好被调度到CPU0，就会出现这个问题。频繁加解锁只是延长了tasklet占用CPU的时间，加速触发watchdog报警。

可行的解决方向 #

• 改用睡眠锁（如mutex）处理workqueue侧的访问：workqueue属于进程上下文，允许睡眠，使用mutex替代spin_lock后，拿不到锁时会主动让出CPU，不会出现忙等死循环。注意tasklet侧仍需使用spin_lock（软中断上下文不能睡眠），需确保两种锁的互斥逻辑正确。
• 绑定workqueue到其他CPU：将workqueue的kworker绑定到CPU1（双核平台的另一个核心），避免和tasklet在同一CPU竞争。这样spin_lock的忙等只会占用CPU1，不会影响CPU0的tasklet执行，锁最终会被释放，kworker能正常获取锁。
• 优化tasklet的锁持有时长：把耗时的操作移出spin_lock的保护范围，或者批量处理数据包减少tasklet的触发频率，降低tasklet占用CPU的时间，给kworker留出获取锁的机会。

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