linux死循环退出

linux死循环退出方法如下：

1、break语句用于跳出linux死循环。continue用于跳过循环中的一个迭代。break语句可用于跳出循环。

2、break语句跳出循环后，会继续执行该循环之后的代码(如果有的话)：continue语句中断循环中的迭代，如果出现了指定的条件，然后继续循环中的下一个迭代。

在开发内核模块或驱动时，如果处理失误，导致内核线程中出现死锁或者死循环，你会发现，除了重启之外，你没有任何可以做的。这时你的输入不起任何作用，终端（不是指远程的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)

什么时候可能出现内核崩溃，kernrl panic呢？

Linux在中断处理程序中，它不处于任何一个进程上下文，如果使用可能睡眠的函数，则系统调度会被破坏，导致kernel panic。因此，在中断处理程序中，是不能使用有可能导致睡眠的函数(例如信号量等)。

在中断发起的软中断中，其上下文环境有可能是中断上下文,同理，也不能调用可能导致睡眠的函数。软中断执行时，全局中断是打开的，而中断程序执行时，全局中断是禁止的。

软中断除了系统调度进入点，当软中断数量频繁时，内核中有一个专门的软中断的后台程序daemon来处理其事务。

还有内核堆栈溢出，或者指针异常访问时，也会出现kernel panic。

堆栈溢出：程序循环或者多层嵌套的深度过多时，可能会导致栈溢出。

显而易见，除0异常、内存访问越界、缓冲区溢出等错误时，当这些事件发生在应用程序时，Linux内核的异常处理机制可以对这些由应用程序引起的情况予以处理。当应用程序出现不可恢复性错误时，Linux内核可以仅仅终止产生错误的应用程序，而不影响其他程序。如果上述 *** 作发生在内核空间，就会引起kernel panic。

还有内核陷入死锁状态，自旋锁嵌套、在内核线程中，存在死循环的 *** 作等等都会引起kermel panic。

---