中断系列第四篇：中断爱养狗？

最近老问一些喂狗的事情，这个也是我学习中断系列的初衷。当时的背景就是中断、看门狗两个关键词，那个时候我年幼还不能把这个两个事情挂上钩。不过在很久以前，也知道单片机整个中断函数，中断函数定时，到了就去喂个狗，防止程序跑飞，那个时候还不知道Linux是个什么？

这一篇的关键词：NMI中断、Watchdog

1、什么是看门狗

Watchdog，又称watchdog timer，是计算机可靠性（dependability）领域中一个极为简单同时非常有效的检测（detection）工具。其基本思想是针对被监视的目标设置一个计数器和一个阈值，watchdog会自己增加计数值，并等待被监视的目标周期性地重置计数值。

一旦目标发生错误，没来得及重置计数值，watchdog会检测到计数值溢出，并采取恢复措施（通常情况下是重启）。总结一下就是计数——溢出——触发。

Watchdog的工作方式是事件触发的，它可以对任何合理的事件计数（如CPU指令）。其中时间事件（timeout）最常使用，这也是为什么watchdog又叫做watchdog timer。但无论watchdog统计什么事件，它的思想都是一样的。

归根结底，Watchdog是一种检测手段，它监视的目标可以是一个进程也可以是整个操作系统。Watchdog的合理性基于这样的假设：一个正常运行的系统，它的执行流应该是可预测的，因此可以在它正常执行路径上设置一些周期性重置watchdog的点；但如果系统发生故障，它可能执行不到下一个重置watchdog的点，此时故障将被watchdog捕捉到。看到这儿，您应该想到watchdog对于检测死循环或死锁这类故障非常有效。

watchdog  中文意思看门狗，是Linux系统中的一个特别重要的监测响应机制，**负责监测系统运行的情况**，**一旦出现锁死，死机的情况，能够及时的重启机器，并收集crash dump**。
又称watchdog timer，是计算机可靠性（dependability）领域中一个极为简单同时非常有效的检测（detection）工具。其基本思想是针对被监视的目标设置一个计数器和一个阈值，watchdog会自己增加计数值，并等待被监视的目标周期性地重置计数值。一旦目标发生错误，没来得及重置计数值，**watchdog会检测到计数值溢出，并采取恢复措施（通常情况下是重启）。总结一下就是计数——溢出——触发。**
无论什么样的机制，都离不开watchdog的基本思路：
+ 1、**系统的某一个事件会被策略设定一个阈值**，这个系统会产生或者关联一个计数器来统计这个值，在watchdog一方也在同步这一个值，当两方**不一样**时，或者计算器上的值**超过了这个阈值**，watchdog的机制就会被激活。
+ 2、watchdog机制被激活以后，会自动通过计数器的数值来判定系统是否已经产生问题，如果结果为是，那么即马上执行watchdog中预先设定的策略或者应急预案。

1、Watchdog的实现

针对不同的监视目标，watchdog可以采取不同的实现方法。

• 监视一个进程
  如果监视目标只是一个进程，那么利用操作系统提供的定时功能即可实现一个watchdog。
  
• 监视一个操作系统
  如果要监视操作系统，就得使用操作系统之外的工具**，通常是一个附加的计数器**。现代Intel CPU都包含的performance counter也可以提供这样的功能，从而不需要额外的设备就能实现监视操作系统的watchdog。
  

关于操作系统watchdog的设计策略以及实现方法，可参考论文"Exploring Recovery from Operating System Lockups"。

watchdog有好几种不同的机制，最主要的还是内核watchdog和userland watchdog。

Linux很早就引进了watchdog，事实上，Linux中有两套watchdog体系：

• The Linux Watchdog driver API
• NMI watchdog

2、The Linux Watchdog driver API

【使用 watchdog 构建高可用性的 Linux 系统及应用】

Linux的文档和man手册

3、NMI watchdog

NMI watchdog是Linux的开发者为了debugging而添加的特性，但也能用来检测和恢复Linux kernel hang，现代多核x86体系都能支持NMI watchdog。（现在ARM也开始支持）

NMI（Non Maskable Interrupt）即不可屏蔽中断，之所以要使用NMI，是因为NMI watchdog的监视目标是整个内核，而内核可能发生在关中断同时陷入死循环的错误，此时只有NMI能拯救它。

NMI watchdog的思想如前所述，仍然是通过计数和阈值进行监控。要打开NMI watchdog，只需要在grub.cfg中添加一句"nmi_watchdog=N"，重启之后NMI watchdog就已经开启了。

Linux中有两种NMI watchdog，分别是I/O APIC watchdog（nmi_watchdog=1）和Local APIC watchdog（nmi_watchdog=2）。它们的触发机制不同，但触发NMI之后的操作是几乎一样的。从名字上看，它们都利用了APIC，所以前面强调这是被现代多核x86体系支持的功能。下面介绍这两种NMI watchdog的监测机制。

(APIC的校角色类似于ARM的GIC)

1、I/O APIC watchdog

如果已经熟悉了Intel APIC架构，那么再来了解Linux NMI watchdog就是易如反掌，相关资料可以先看看这篇《Linux内核中断内幕》热热身，然后看完最新的Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3: System Programming Guide的第10章《Chapter 10 Advanced Programmable Interrupt Controller (APIC)》就够了，没有什么资料比Intel手册更详尽了。

I/O APIC watchdog的工作方式比较奇葩，一旦开启了I/O APIC watchdog（nmi_watchdog=1），那么每个CPU对应的Local APIC的LINT0线都关联到NMI，这样每个CPU将周期性地接到NMI（这个周期与Local timer的周期相同），接到中断的CPU立即处理NMI。处理的过程就是检查CPU的irq_stat（统计CPU中断信息的结构体，多核系统中这将是个数组）中的apic_timer_irqs和irq0_irqs这两个字段的和，它们分别代表了当前CPU从启动到现在处理的本地时钟中断次数和全局时钟中断次数。如果这两个值的和在一定时间（在我的机子上是5秒）之内都没有增加，说明这个CPU已经连续5秒没有处理过一次时钟中断，显然，出大事了。

2、Local APIC watchdog

想了解Local APIC watchdog也需要先看Intel手册……仍然是最新的Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3: System Programming Guide，第18章《Chapter 18 Performance Monitoring》。这一章列出了Intel所有体系的PM，内容超多，但只要看

• 18.2.3 Pre-defined Architectural Performance Events
• 18.17 Performance Monitoring (P6 Family Processor)
• 18.18 Performance Monitoring (Pentium Processors)

这三部分就足矣。如果觉得Intel手册内容太多或者看英文比较吃力，可以参考张银奎老师的《软件调试》第5.5节，《性能监视》。

Intel CPU带有performance counter，可以对的许多事件计数（P4系列多达43到45个，具体数目视型号而定），在watchdog中，统计的事件是"UnHalted Core Cycle"，即CPU处于非halt状态下经过的周期数。当计数溢出时，Local APIC会向CPU发出一个PMI（performance counter interrupt）。PMI的属性可选，理所应当的，在Local APIC watchdog中它被设置成NMI。利用这个特性，就能周期性地产生NMI。

发出NMI之后，Local APIC watchdog的行为就与I/O APIC watchdog几乎一样了，仍然是检查CPU处理时钟中断的次数。唯一的区别是，在处理NMI的过程中还多执行一项操作：重置performance counter。由于Local APIC watchdog统计的是UnHalted Cycles，所以系统空闲的时候，NMI触发的频率比较低。

3、小结

对比两种NMI watchdog，其实各有长短。

I/O APIC watchdog的缺点很明显……每个时钟周期都要触发NMI，这对性能是个不小的影响，引用Linux Document的原话"…its NMI frequency is much higher, resulting in a more significant hit to the overall system performance"，而且可靠性不太好。我开启watchdog之后，写了个关中断+死循环的kernel module并且加载到系统中，结果Linux跪了——这意味着I/O APIC watchdog没起作用。

Local APIC watchdog的触发频率要低一些，性能开销也要小一些。但是注意它统计的事件，“UnHalted Core Cycle”，也就是说，万一CPU进入了关中断+halt的状态，那它也没救了，因为这时候计数器根本就不走了。但是I/O APIC watchdog却没有这个缺陷。但是就可靠性而言，Local APIC watchdog的表现更好，我开启它之后通过module注入了各种spinlock死锁，它居然都恢复了……（halted:(使)停止，停下）

Postscript

以上关于两种NMI watchdog的说明，我已经省去了很多很多细节（=_=），尤其是初始化。I/O APIC watchdog的初始化细节在arch/x86/kernel/apic/apic.c；Local APIC watchdog的全部实现都在arch/x86/perfctr_watchdog.c。Local APIC watchdog的初始化看得我都要吐血了-.-

4、Postscript（后记）

I/O APIC watchdog的初始化细节在arch/x86/kernel/apic/apic.c；Local APIC watchdog的全部实现都在arch/x86/perfctr_watchdog.c。Local APIC watchdog的初始化看得我都要吐血了-.-（牛啊牛啊）

为了彻底了解Linux NMI watchdog的工作原理，我尝试了各种途径：

• Google
• BBS
• Stack Overflow
• Intel Manual
• Linux Document
• E-mail
• Source code

这点后记有点意思，不能丢弃。

1、没有完美的代码

没有完美的人，更没有完美的代码。虽然教科书上说deadlock（死锁）多么不好不好，但是在现实生活中，很难把它完全消灭。假 设不小心内核出现了deadlock，可能你得干瞪眼。CPU就在那里空等着，空转着，叫天天不应，叫地地不灵。等到海枯石烂，CPU生锈的那一天，它还 会那么痴痴地等着那个霸占了锁的家伙会良心发现，解下这个锁。也许你会说，哎呀，这么麻烦干嘛？RESET一下，不就一了百了吗？但是如果是一台肩负重担 的Server（服务器），在夜深人静你正呼呼大睡的时候发生了deadlock呢？如果deadlock的原因没有查到，三天五天就会发生一次，光这样 被动的重启也不是办法……

不用说让人心惊胆颤的deadlock，很多时候，一段小小的循环，就会把你彻底雷到。我们总认为循环是可以结束的，但是别要忘 记，事物都是辩证的，有的时候，碰巧发生了某些预料之外的条件，让这个循环成了彻彻底底的死循环。恰巧此时，CPU的中断如果已经被禁掉，那神仙也救不了 你。“我佛慈悲，能不能把循环给我停掉？”“阿弥陀佛，神仙也得遵守潜规则，你让我给你停掉循环，好歹也要给我一个中断，让我能够施法吧？”……不能怪父 母，更不能怪政府，如果你正好在电脑旁边，可以RESET；如果你不在旁边，就等着老板的电话吧。“小福啊，今天又超过100位客户打电话投诉我们的交友 网站不能访问了，你赶紧打的到公司，看看是怎么回事。赶紧啊！有个客户说，如果今晚12点之前不能登录网站，取得要约会的5位MM的详细资料，他就会携带 人体炸弹到办公楼来砸场子……“

2、保留现场，强行重启

言归正传。如果应用程序进入死循环，我们可以把它KILL掉。如果内核因为意料之外的原因，导致系统进入无法自拔的死循环，最好的 办法就是让系统给强行重启。当然，这种重启最好是自动的，不需要人干预的，且最好能够打印出导致重启的原因，便于开发者调试错误。在Linux内核中，用 NMI看门狗（NMI Watchdog Timer)的方式来实现该机制。

在系统的正常运行过程当中，每秒都有非常多的中断产生。即便它啥都不做，啥外部中断都不接收，每秒至少有数以百计的用来给线程调度的时钟中断。（如果调度时间片为10ms，则有100个时钟中断。）假设如果内核发现5秒钟之内，没有产生一个中断，那将会是怎么一回事呢？

这个时候，CPU会辩解道：“我兢兢业业地执行每一条指令，有没有中断不干我的事，叫我干啥就干啥，我是真正的劳动模范，不要怀疑 我会捣鬼。中断既来之，我就安之。不来之，则说明中断已经被禁掉了。肯定是有个幕后黑手已经调用CLI之类的指令关闭了全局的外部中断，然后偷偷摸摸干自 己相干的事情，不被其他人给打断。人都有自己的隐私嘛，代码也不例外。屏蔽中断，执行不被打断的代码，人之常情。但是用得不恰当，如同毒品一样，就会出现 大问题。少量鸦片，可以当作药品；携带超过5克海洛因，就得上刑场。禁掉中断占用一点点CPU时间，可以让程序很容易地绕开race condition（竞争条件）；但是如果中断被禁掉的时间长达5秒钟，那就违反常理了。5秒钟之内系统不会有其他响应，其影响之深远，罪行之恶劣，不用 满清十大酷刑简直不足以平息民愤……”

“该杀！该杀！”这个时候，内存，芯片组，硬盘……所有硬件都附和。看来CPU还是一直是IT届的老大。不怪我们不客气了，赶紧打 印出现场（CPU出现LOCKUP时的相关上下文，包括寄存器值，函数调用栈等），且记入LOG，作为判案的证据，同时有警示后人只用。接着，就对施以极 刑，给内核来一个oops，彻底终止它的执行，让它重新启动。

3、少林扫地僧——NMI

不对，不对！也许你有这样的感觉，既然5秒之内没有一个中断，基本肯定中断是已经被禁掉了，那CPU就被迫只会一直执行那段有问题 的代码，根本没有机会来执行所谓的“保留现场，强行重启”的代码。这些代码放在内核的另外一个地方，要调用它，必须由中断出发。可是，可是中断不是已经被 禁了吗？借尸还魂？恐怖，恐怖……

“再厉害的黑社会，也斗不过我们人民警察！”这个时候，CPU又冷笑了，“虽然中断被禁掉了，但是，我还拥有秘密武器。那就是 Non-maskable interrupt，不可屏蔽中断，简称NMI。你要禁，只能禁掉一般的可屏蔽中断。NMI，我压根就让你摸不着，碰不着！”

原来，内核中隐藏着一个神秘的高手，那就是NMI。我们调用spin_lock_irq，虽然能够禁掉本地的中断，但是NMI却不 行。内核中设置了一个watchdog timer，它的中断类型就被置为NMI，每过一定的时间，这个timer就执行一次，用来悄悄监视系统的运行。如果系统正常，它啥事都不做，仅仅是更改 一些时间计数；如果系统不正常（默认5秒没有任何普通外部中断），那它就闲不住了，会立马跳出来，且中止之前程序的运行。该出手时就出手！

我想到了在血腥的武林当中，有无数的高手。刚开始的时候，似乎人人都是高手；但后来，昔日的高手看起来都是菜鸟，强中更有强中手。 再后来，更高的高手出来了，开始这里论剑那里比武，争霸天下了。最后来，天下也许是第一第二的高手开始决战……似乎故事就这个时候结束了，但是让人大跌眼 镜的是，一个小小的少林扫地僧，却能轻易地两位顶尖高手制服。NMI就是这样的角色，平时从不站在前台，也很少为人所知。除了用NMI watchdog timer监测系统是否锁住之外，一些特殊的严重的硬件错误，比如内存奇偶校验错等，也会触发NMI的发生。不过这些错误，估计很多人从来不会碰到过。

4、More…

如果出现死循环的地方没有把中断禁掉，那是不是不会触发NMI watchdog timer了呢？理论上是的。至少Linux2.6的抢占内核应该不会触发。但是，由于系统还是有机会调度到其他线程，所以整个系统可能响应很慢，但不至 于给死掉。我们可以通过top命令查看进程状况等手段来进行分析。

不是所有的Linux内核都支持NMI watchdog timer的。必须在内核中添加APIC的支持。（现在的内核和硬件一般都是没有问题的）如果是x86-64的硬件体系结构，APIC是被默认支持的。在很多发行版本当中，需要在启动的时候添加内核启动参数

nmi_watchdog=N

来启动NMI watchdog timer。N代表了该timer的source，如果为1，表示利用IO APIC的始终源；如果为2，表示利用LOCAL APIC的performance counter。具体哪个好用，可以分别测试一下，**一般来说，比较新的CPU（一般都是双核了）选择2的话，系统负担更小一点。**想要更多的了解NMI watchdog timer，请看如下的kernel文档

http://www.kernel.org/doc/Documentation/nmi_watchdog.txt

想要知道啥时APIC（注意不是ACPI），啥是IO APIC，啥是LOCAL APIC，那就请google一下吧。

5、整个栗子

nmi_watchdog原理(用于检测关中断死锁)

nmi_watchdog用于检测内核中关中断死锁(也称硬死锁)的情况，是调测内核死机或死锁问题的一大利器。

内核中，如果代码编写不好可能会出现关中断死锁的情况，即进入内核态后，关中断，然后在内核态中死锁，或长时间运行，导致该CPU无法响应中断(因为中断已关)，也无法得到调度(对于没有启用内核抢占的内核来说)，外在表现可能为系统挂死、无法ping通、没有响应。而nmi_watchdog正是针对这种情况而设计的。

其基本原理为：注册nmi中断(3号中断)，为不可屏蔽中断，由硬件定期触发(通过性能计数器)。在时钟中断中更新相关计数器，在nmi中断处理中，判断相关计数器是否更新，如果超过5s(默认情况下)没有更新，则触发nmi_watchdog，默认情况下，最终会进入panic流程。

2.6.11代码流程如下：

本地时钟中断处理函数：

fastcall void smp_apic_timer_interrupt(struct pt_regs *regs)
{
 /**
  * 获得CPU逻辑号
  */
 int cpu = smp_processor_id();
 /*
  * the NMI deadlock-detector uses this.
  */
 /*增加apic_timer_irqs计数，此计数用于nmi_watchdog，其会在do_nmi中检测这个值的更新状态 */
 irq_stat[cpu].apic_timer_irqs++;
...
}

nmi中断的处理函数：do_nmi->default_do_nmi()

static void default_do_nmi(struct pt_regs * regs)
{
...
if (nmi_watchdog) {
            nmi_watchdog_tick(regs);
            return;
...
}

nmi_watchdog检测函数：nmi_watchdog_tick()

void nmi_watchdog_tick (struct pt_regs * regs)
{
    int sum, cpu = smp_processor_id();
    sum = irq_stat[cpu].apic_timer_irqs;
//检测irq计数是否更新，如果没更新，则表示可能发生关中断死锁了。
    if (last_irq_sums[cpu] == sum) {
        /*
         * Ayiee, looks like this CPU is stuck ...
         * wait a few IRQs (5 seconds) before doing the oops ...
         */
        alert_counter[cpu]++;
//如果5s内，计数都没有更新，那就触发die_nmi()，最终会走panic流程。
        if (alert_counter[cpu] == 5*nmi_hz)
            die_nmi(regs, "NMI Watchdog detected LOCKUP");
    } else {
        last_irq_sums[cpu] = sum;
        alert_counter[cpu] = 0;
    }
...
}

获益良多的文章，感恩前辈！！！