soft lockup的分类和定位方法

我之前已经写了lockup问题的检测原理，https://blog.csdn.net/rikeyone/article/details/112004920，本来就来尝试梳理一下soft lockup问题触发场景和解决方法。

首先需要明确一点soft lockup是一类问题，引起它的原因也是各有不同，本文只是尝试做一些梳理，把一些具有共通性的特点的问题做一些总结，可能存在有不全面的地方。

第一种场景：spinlock死锁场景
对于这种场景，其实很好理解，当A-B/B-A死锁发生的时候，两个进程分别去获取对方持有的锁，那么又都是spinlock，我们知道spinlock是会关闭抢占的，并且是忙等待锁，最终会造成执行CPU上的watchdog线程无法被调度执行。这是比较好理解的一个场景。

针对这个场景如何识别呢，我们从内核crash的堆栈中是可以看得一二的，肯定会有一些进程的堆栈是处于获取锁的过程中的，可以在调用栈中看到spin_lock相关的一些函数调用。那么针对这一种场景，我们可以利用crash去查找到spinlock结构体，并定位持有该锁的进程，如果两个进程互相持有对方要获取的锁，那么基本确认是这种死锁类型了。

第二种场景：内核繁忙
所谓的内核繁忙，也就是说内核长时间的在处理事务，而watchdog得不到执行，那么假如我在自己的内核模块中写了一个死循环，那么是不是一定会触发soft lockup呢？其实不然，死循环执行并不一定会导致soft lockup，那是因为进程的运行是受到内核调度器管理的，并不是你写个死循环，它就会一直占用CPU不释放，这种理解是不对的。

那么什么情况下的内核繁忙才会引起soft lockup呢？

实际上，当我们禁止调度或者持有自旋锁之后，执行了一个很耗时的任务，那么就很可能会触发该问题，因为调度被关闭以后，CPU就归当前的进程所有了，watchdog线程也就无法得到调度了。

关于持有自旋锁后执行繁忙任务的场景，读者可能会觉得这一条应该被归于第一种场景。因为进程持有的锁在其他进程尝试获取时就相当于发生了死锁，那么就变成了第一种场景，不过我写在这里实际上是考虑的另一种情况：长时间持有自旋锁。
假如有进程A进入内核态后持有了spinlock，并运行了繁重的任务，需要耗时很长，并且一直也没有其他进程去获取该锁，那么它同样会因为内核繁忙而导致soft lockup。这里的关键就是spinlock暗含了关闭抢占的操作，导致持有锁的CPU上，watchdog线程无法被调度执行。

另一个例子：在NUMA系统中，对于一个共享变量的访问，如果采用了读写锁，有大量读者时，可能导致写锁一直获取不到，特别是NUMA系统中不同CPU对内存的访问时间也不同。

再比如：内核持有锁的情况下执行了大量对象的扫描、释放、申请动作等等。

第三种：虚拟机中资源获取受限

笔者是在云厂商工作，所以第三种呢，考虑到的是虚拟机场景， 通过redhat提供的一些案例中可知，如果发生soft lockup的地方是很随机没有规律的，并且有一些地方代码上看是不可能发生soft lockup的地方，那么就需要考虑是虚拟化引入的问题，对于物理机器来说，一个soft lockup很可能是内核的bug或者硬件的bug，而对于虚拟机场景，还有一种可能就行虚拟化机制带来的overcommit(especially memory overcommitment or other virtualization overheads）， 比如 hypervisor not scheduling virtual CPUs in timely manner。

IPI中断超时响应

在虚拟机场景下，对于soft lockup我遇到过多例都是soft lockup死在了ipi请求过程中，特别是函数smp_call_function_many中：

PID: 12263  TASK: ffff8803bbebdee0  CPU: 2   COMMAND: "kworker/u8:0"
bt: page excluded: kernel virtual address: ffffffffffffffff  type: "cpu_online_map"
 #0 [ffff88043fd03cf8] machine_kexec at ffffffff8105c4cb
 #1 [ffff88043fd03d58] __crash_kexec at ffffffff81104a32
 #2 [ffff88043fd03e28] panic at ffffffff8169dc5f
 #3 [ffff88043fd03ea8] watchdog_timer_fn at ffffffff8112f651
 #4 [ffff88043fd03ee0] __hrtimer_run_queues at ffffffff810b4ae4
 #5 [ffff88043fd03f38] hrtimer_interrupt at ffffffff810b507f
 #6 [ffff88043fd03f80] local_apic_timer_interrupt at ffffffff81053895
 #7 [ffff88043fd03f98] smp_apic_timer_interrupt at ffffffff816b76bd
 #8 [ffff88043fd03fb0] apic_timer_interrupt at ffffffff816b5c1d

--- <IRQ stack> ---

 #9 [ffff88000399b738] apic_timer_interrupt at ffffffff816b5c1d
    [exception RIP: smp_call_function_many+514]
    RIP: ffffffff810f99a2  RSP: ffff88000399b7e8  RFLAGS: 00000202
    RAX: 0000000000000003  RBX: 00000000000000fc  RCX: ffff88043fd9adb8
    RDX: 0000000000000003  RSI: 0000000000000004  RDI: 0000000000000000
    RBP: ffff88000399b820   R8: ffff88017a1ee000   R9: ffffffff813227d9
    R10: ffff88043fd19c80  R11: ffffea00000c2100  R12: 0000000000000292
    R13: ffff88000399b798  R14: ffffea0010b1f842  R15: 0000000000000000
    ORIG_RAX: ffffffffffffff10  CS: 0010  SS: 0018
#10 [ffff88000399b828] native_flush_tlb_others at ffffffff8106e668
#11 [ffff88000399b878] flush_tlb_page at ffffffff8106e864

对于soft lockup发生在ipi请求过程中的案例，实际上是有一个固定的步骤进行排查的，一般都是由于发送ipi请求的一方发送请求后，一直在忙等待请求函数的执行完成，而执行CPU一直没有正常执行该函数导致了soft lockup。对于这类问题首先需要找到导致soft lockup的CPU上的堆栈，根据堆栈信息查找到函数的入口参数，一般包括目标CPU和对应的csd结构体，通过这两个信息来确定哪个CPU在执行请求，查看对应CPU上的堆栈以及运行队列，从而确认该CPU是否处于繁忙状态，以及当前在运行什么操作。通过这两点确定是否可能造成死锁或者长时间无响应的情况。

如果以上步骤发现都没有问题，假如是虚拟机环境，那么大概率是宿主机上的qemu进程出问题了，比如处于D状态了，从而导致vcpu调度也出现问题。

参考
https://access.redhat.com/articles/5008811
https://access.redhat.com/solutions/1503333
https://www.suse.com/support/kb/doc/?id=000018705
https://access.redhat.com/solutions/658783