一. 整体介绍
soft lockup：检测调度异常， 一般是驱动禁止调度或者阻塞比如while(1)， 导致无法调度其他线程， 需要注意的是， 应用程序while(1)不会影响其调度， 只要有更高的优先级出现会在时间滴答（10ms）选中并切换进程，
但如果是在驱动也即内核态， 即使有更高优先级时间滴答也不会切换线程， 只不过会在该线程的task->flag 标志 NEED_RESHEDULE， 驱动还是会继续跑， 简单说就是驱动while(1) 会独占CPU 资源， CPU
不会调度到其他进程/线程， 只有中断产生， 才能打断其运行， soft lockup就是根据这个， 利用中断在中断上下文来判断调度是否阻塞了， 怎么判断呢？ 先创建一个内核线程（watchdog/xx）， 且优先级设置
实时优先级FIFO， 功能就只是更新时间戳到某个变量（watchdog_touch_ts）， 这个线程在每一轮调度总能排在前面， 设想如果连这个线程都得不到运行， 其它普通线程还有机会么？ 中断函数watchdog_timer_fn()
会读取这个变量watchdog_touch_ts存的时间戳和此时的时间戳， 如果相差大于20秒， 则说明进程阻塞了， 否则说明进程运行正常， 这里需要强调的是超过20秒是指线程watchdog/xx在20秒内都没得到运行，
可能是一个驱动while(1)导致的， 也可能是多个进程阻塞几秒钟， 全部累计时间超过20秒， 甚至是中断函数做一下耗时处理导致的， 总而言之是系统其他总时间超过20秒， 导致watchdog/xx没有被调度， 但这
并不一定意味是有问题的， 假设如果你的系统很变态， 跑了100个应用/进程， 每个耗时0.3秒， 那系统轮询所有的进程需要的时间就是30秒， 产生这个异常很正常， 所以要改这个默认20秒异常时间值， 可以
改成40秒就行了， 当然绝大部分系统20秒足够让进程轮了好多次了~~~
hard lockup：检测中断异常， 一般是禁止中断或者某个中断函数内阻塞， 导致其他中断无法得到执行， 中断是系统得以运行的重要保证， 出了异常系统不可控！ 那问题来了， soft lockup是靠中断来监控进程， 那谁来监控
中断那就是NMI（不可屏蔽中断）或者FIQ（一般系统的中断都是IRQ）， 总之就是要比普通中断更高级！ 具体做法也简单， 上面已经有个中断监控函数watchdog_timer_fn() 里面除了判断soft lockup， 还会对
hrtimer_interrupts进行加1， 不可屏蔽中断watchdog_overflow_callback()会对上一次存放的值hrtimer_interrupts_saved和这次hrtimer_interrupts对比， 如果一样说明定时器中断函数watchdog_timer_fn()没有得到运行！
二. 源码分析
1. soft lockup：
其实就是为每个CPU创建内核线程--watchdog/xx， 里面就只是更新时间戳而已（__touch_watchdog()）， 只不过这个线程内核会有个while(1)大循环， 没必要老更新时间戳，
所以多个判断函数 -- watchdog_should_run(), 当然也可以在线程函数改成msleep(4000）也行
如何判断线程调度超时呢？
static int is_softlockup(unsigned long touch_ts) //watchdog_touch_ts
{
unsigned long now = get_timestamp(); if (watchdog_enabled & SOFT_WATCHDOG_ENABLED) {
/* Warn about unreasonable delays. get_softlockup_thresh() = 20秒 */
if (time_after(now, touch_ts + get_softlockup_thresh()))
return now - touch_ts;
}
return ;
}
now就是此刻时间， 参数是线程上次更新后的时间戳值， get_softlockup_thresh() = 20秒， 如果if为true， 说明这个线程已经过了20秒都没更新时间戳， 有问题！ 在哪里判断呢？ 在定时器中断watchdog_timer_fn()函数中，
这个定时器中断也是每个CPU都有的， 所以也放置在线程的初始化函数内 -- .setup = watchdog_enable(), 同时设置改线程为SCHED_FIFO 实时进程！
static void watchdog_enable(unsigned int cpu)
{
struct hrtimer *hrtimer = raw_cpu_ptr(&watchdog_hrtimer); /* kick off the timer for the hardlockup detector */
hrtimer_init(hrtimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
hrtimer->function = watchdog_timer_fn; /* Enable the perf event */
watchdog_nmi_enable(cpu); /* done here because hrtimer_start can only pin to smp_processor_id() */
hrtimer_start(hrtimer, ns_to_ktime(sample_period),
HRTIMER_MODE_REL_PINNED); /* initialize timestamp */
watchdog_set_prio(SCHED_FIFO, MAX_RT_PRIO - );
__touch_watchdog();
}
在中断函数中， 每产生一次中断， 判断该线程是否超时了, 超时的话就打印log“BUG: soft lockup - CPU#%d stuck for %us!”。 另外， 线程不是一直在跑， 只有在hrtimer_interrupts更新时候才会跑否则shedule出去， 所以在这更新后要唤醒线程！
static enum hrtimer_restart watchdog_timer_fn(struct hrtimer *hrtimer)
{
unsigned long touch_ts = __this_cpu_read(watchdog_touch_ts);
struct pt_regs *regs = get_irq_regs();
int duration;
int softlockup_all_cpu_backtrace = sysctl_softlockup_all_cpu_backtrace; /* kick the hardlockup detector hrtimer_interrupts++ */
watchdog_interrupt_count(); /* kick the softlockup detector */
wake_up_process(__this_cpu_read(softlockup_watchdog)); ...............
duration = is_softlockup(touch_ts);
}
2. hard lockup
hardlockup比较简单， 就是注册一个周期为10秒的不可屏蔽中断函数watchdog_overflow_callback()， 里面判断是否超时：
static int is_hardlockup(void)
{
unsigned long hrint = __this_cpu_read(hrtimer_interrupts); if (__this_cpu_read(hrtimer_interrupts_saved) == hrint)
return ; __this_cpu_write(hrtimer_interrupts_saved, hrint);
return ;
}
由于不可屏蔽中断是10秒产生一次， 而定时器中断每4秒产生一次， 所以hrtimer_interrupts必然不等于hrtimer_interrupts_saved， 且将hrtimer_interrupts赋值到hrtimer_interrupts_saved进行更新，
如果哪次相等， 说明这10秒钟内该定时器中断都没有被执行！ 从而打印"Watchdog detected hard LOCKUP on cpu %d"
当然触发后是警告式打印还是panic挂死系统取决用户的配置！ 毕竟前面我说了， 有可能触发是正常现象， 如果是正常现象用户应该更改超时时间阈值， 不过我习惯panic()， 早发现早解决！
三、测试代码
softlockup测试用例， 如果针对SMP， 可以多创建几个线程以及绑定CPU
#include <linux/module.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/gpio.h>
#include <linux/of_gpio.h>
#include <linux/delay.h>
#include <linux/kthread.h> int test_thread0(void *data)
{
int cnt=; printk("I will block CPU0\n");
msleep();
printk("block CPU0\n");
while(){
mdelay();
printk("[CPU%d]block CPU %ds\n", raw_smp_processor_id(), ++cnt);
} } static int test_init(void)
{
struct task_struct *test_task0; printk("Vedic init.....\n"); test_task0 = kthread_create(test_thread0, NULL, "test_thread0");
if(IS_ERR(test_task0)) {
printk("test_task0 fail\n");
return ;
}
kthread_bind(test_task0, );
wake_up_process(test_task0); return ;
} static void test_exit(void)
{
printk("Vedic exit......\n");
} module_init(test_init);
module_exit(test_exit); MODULE_LICENSE("Dual BSD/GPL");
MODULE_AUTHOR("Vedic <[email protected]>");
四、 其他
a. 上面的测试用例我在单核上出现softlockup panic， 但双核却没有， 甚至我开两个线程分别绑定CPU0/CPU1都正常运行， 怀疑跟系统的负载均衡有关， 即线程绑定某个CPU不会一直就在该CPU上运行的！
b. 无论是soft还是hard触发打印当前的线程， 都不能判定就是凶手， 只能说系统有问题， 需要进一步排查。
c. hard lockup依赖处理器有没有NIM中断， 没有的话无法实现