Linux soft lockup 和 hard lockup

一. 整体介绍

　　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 0;
}

　　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 - 1);
    __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 1;

    __this_cpu_write(hrtimer_interrupts_saved, hrint);
    return 0;
}

　　由于不可屏蔽中断是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=0;

    printk("I will block CPU0\n");
    msleep(3000);
    printk("block CPU0\n");    
    while(1){
        mdelay(1000);
        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 0;
    }
    kthread_bind(test_task0, 0);
    wake_up_process(test_task0);

    return 0;
}

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 <FZKmxcz@163.com>");

 

四、 其他

　　a. 上面的测试用例我在单核上出现softlockup panic， 但双核却没有， 甚至我开两个线程分别绑定CPU0/CPU1都正常运行， 怀疑跟系统的负载均衡有关， 即线程绑定某个CPU不会一直就在该CPU上运行的！

　　b. 无论是soft还是hard触发打印当前的线程， 都不能判定就是凶手，  只能说系统有问题， 需要进一步排查。

　　c. hard lockup依赖处理器有没有NIM中断， 没有的话无法实现