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)

在linux内核中，有大量的数据结构需要用到双循环链表，例如进程、文件、模块、页面等。若采用双循环链表的传统实现方式，需要为这些数据结构维护各自的链表，并且为每个链表都要设计插入、删除等 *** 作函数。因为用来维持链表的next和prev指针指向对应类型的对象，因此一种数据结构的链表 *** 作函数不能用于 *** 作其它数据结构的链表。

Linux调度时机主要有：

1、进程状态转换的时刻：进程终止、进程睡眠。

2、当前进程的时间片用完时（current->counter=0）。

3、设备驱动程序。

4、进程从中断、异常及系统调用返回到用户态时。

时机1，进程要调用sleep（）或exit（）等函数进行状态转换，这些函数会主动调用调度程序进行进程调度。

时机2，由于进程的时间片是由时钟中断来更新的，因此，这种情况和时机4是一样的。

时机3，当设备驱动程序执行长而重复的任务时，直接调用调度程序。在每次反复循环中，驱动程序都检查need_resched的值，如果必要，则调用调度程序schedule()主动放弃CPU。

时机4，如前所述，不管是从中断、异常还是系统调用返回，最终都调用ret_from_sys_call（），由这个函数进行调度标志的检测，如果必要，则调用调用调度程序。

从系统调用返回意味着要离开内核态而返回到用户态，而状态的转换要花费一定的时间，因此，在返回到用户态前，系统把在内核态该处理的事全部做完。

在Linux中，进程的运行时间不可能超过分配给他们的时间片，他们采用的是抢占式多任务处理，所以进程之间的挂起和继续运行无需彼此之间的协作。

在一个如linux这样的多任务系统中，多个程序可能会竞争使用同一个资源，在这种情况下，我们认为，执行短期的突发性工作并暂停运行以等待输入的程序，要比持续占用处理器以进行计算或不断轮询系统以查看是否有输入到达的程序要更好。

我们称表现好的程序为nice程序，而且在某种意义上，这个nice 是可以被计算出来的。 *** 作系统根据进程的nice值来决定它的优先级，一个进程的nice值默认为0并将根据这个程序的表现不断变化。长期不间断运行的程序的优先级一般会比较低。

---