Linux内核线程死锁或死循环之后如何让系统宕机重启

在开发内核模块或驱动时，如果处理失误，导致内核线程中出现死锁或者死循环，你会发现，除了重启之外，你没有任何可以做的。这时你的输入不起任何作用，终端（不是指远程的ssh工具）只会在那重复的输出类似BUG: soft lockup - CPU#0 stuck for 67s! [fclustertool:2043]，更无奈的是你重启之后导致系统挂起的堆栈信息也看不到，你所能做的就是一遍遍的加调试信息，一遍遍的重启机器（这是我的经历，现在想想很傻）。

这种情况你肯定不是第一个遇到的，所以内核肯定会提供处理这种情况的一些机制。但是如何来找到这些机制在哪个地方，或者说根据什么信息去google呢？最有用的就是这句话BUG: soft lockup - CPU#0 stuck for 67s! [fclustertool:2043]，因为这句话提供你的信息量很大。首先，这条信息可以输出，说明即使发生死锁或者死循环，还是有代码可以执行。第二，可以通过这个日志信息，找到对应的处理函数，这个函数所在的模块就是用来处理CPU被过度使用时用到的。所以通过这个事情，可以看到内核打印出的只言片语都有可能成为你解决问题的关键，一定要从重视这些信息，从中找出有用的东西。

我经常看的内核版本是官方的2.6.32内核，这个版本中我找到的函数是softlockup_tick()，这个函数在时钟中断的处理函数run_local_timers()中调用。这个函数会首先检查watchdog线程是否被挂起，如果不是watchdog线程，会检查当前占有CPU的线程占有的时间是否超过系统配置的阈值，即softlockup_thresh。如果当前占有CPU的时间过长，则会在系统日志中输出我们上面看到的那条日志。接下来才是最关键的，就是输出模块信息、寄存器信息和堆栈信息，检查softlockup_panic的值是否为1。如果softlockup_panic为1，则调用panic()让内核挂起，输出OOPS信息。代码如下所示：/** This callback runs from the timer interrupt, and checks

* whether the watchdog thread has hung or not:*/void softlockup_tick(void){int this_cpu = smp_processor_id()

unsigned long touch_timestamp = per_cpu(touch_timestamp, this_cpu)

unsigned long print_timestamp

struct pt_regs *regs = get_irq_regs()

unsigned long now

/* Warn about unreasonable delays: */

if (now <= (touch_timestamp + softlockup_thresh))returnper_cpu(print_timestamp, this_cpu) = touch_timestamp

spin_lock(&print_lock)

printk(KERN_ERR "BUG: soft lockup - CPU#%d stuck for %lus! [%s:%d]

",

this_cpu, now - touch_timestamp,

current-comm, task_pid_nr(current))

print_modules()

print_irqtrace_events(current)if (regs)show_regs(regs)elsedump_stack()

spin_unlock(&print_lock)

处理死锁的策略

1.忽略该问题。例如鸵鸟算法，该算法可以应用在极少发生死锁的的情况下。为什么叫鸵鸟算法呢，因为传说中鸵鸟看到危险就把头埋在地底下，可能鸵鸟觉得看不到危险也就没危险了吧。跟掩耳盗铃有点像。

2.检测死锁并且恢复。

3.仔细地对资源进行动态分配，以避免死锁。

4.通过破除死锁四个必要条件之一，来防止死锁产生。

检测死锁的代价很大。所有的类unix系统包括Linux对死锁不作任何处理,这是因为基于成本的考虑.选择鸵鸟算法

---