一、简介
Linux系统在运行过程中，可能发生各种各样的卡死情况。有的表现为某个或某些CPU无法调度其他进程或无法响应中断，如正在CPU上运行的进程禁止了抢占或禁止了本地中断后，但其需要的资源一直无法获得（如发生了死锁等情况），而一直占据着CPU；有的表现为某些重要进程一直不能运行，虽然不至于使某个或某些CPU上无法调度其他进程，但由于重要进程运行异常，系统已无法正常进行业务处理，例如重要进程长期处于uninterruptible sleep状态（也就是常说的D状态）或android systemserver的watchdog超时等情况。
本文主要讨论进程长期处于D状态或重要进程异常卡住的检测方法，即hungtask detect机制。而恢复机制，一般就是在检测到异常时，直接触发整机重启。
二、hungtask detect原理及流程
hungtask detect方法有多种，原理都很简单。比如：
A、可以定时轮询系统中的所有task，然后判断处于D状态的task的上下文切换次数是否和之前轮询时的相等，如果相等则表明该task两个轮询间隔期间一直处于D状态，可以认为该task有hang的情况。当然，task hang住的情况，对于有些task来说没有关系，可能其本身的逻辑就是如此，不会对系统中其它task产生影响；但对于一些我们认为重要的进程，如android中的systemserver、surfaceflinger等进程，如果发生hang的情况，则一定会对用户使用产生影响；还有task长时间处于io wait状态，同样是一种异常状态，因为一般来说io应尽快结束，而时间过长则表明io子系统很可能已经异常。
B、如果只是判断系统中的重要进程是否卡住，也可以不检查系统中所有task的状态，只需要关注重要进程的运行情况。可以让这个重要进程在规定时间内模拟喂狗操作，若发现没有及时喂狗，则认为该重要进程已经卡住。
以下分别讨论上面所述的两种hungtask detect实现方式，所列代码均为开源代码，代码链接见附录参考文档。
1、轮询系统中的所有任务
这里对轮询系统中的所有任务的hungtask detect方式进行分析，代码见参考文档1，主要涉及代码：
kernel\hung_task.c （linux系统默认实现）
drivers\soc\qcom\hung_task_enh.c （在默认实现上进行vendor hook）
KCONFIG
lib\Kconfig.debug （对应hung_task.c ）
drivers\soc\qcom\Kconfig （对应hung_task_enh.c）
资料直通车：Linux内核源码技术学习路线+视频教程内核源码
代码分析
kernel\hung_task.c
A. 将panic_block（notifier_block结构体）挂到panic_notifier_list通知链，当系统发生panic时，会通过该通知链通知注册到该链的所有notifier_block，调用每个notifier_block的notifier_call成员函数。
对于这里的hungtask，就是在panic时调用hung_task_panic函数置did_panic为1，在hungtask检测流程中发现did_panic为1，则直接退出。
B. hungtask_pm_notify_nb（notifier_block结构体）挂到pm_chain_head通知链，当系统发生pm状态变化时调用hungtask_pm_notify，设置hung_detector_suspended变量。
C. 起内核线程，运行D状态检测函数watchdog()，下面分析。
A. 取sysctl_hung_task_timeout_secs和sysctl_hung_task_check_interval_secs最小值作为检测时的interval，加上次检测时间hung_last_checked，如达到或超过当前时间jiffies则进行hungtask check。
B. hungtask check函数，下面详细分析。
C. 进入可中断休眠，如有信号提前中断唤起该线程，会在A处的时间判断中确定是否进行hungtask check。
A. 限制进行hung check的task数量，本轮检测的task数量达到该值后退出。
B. 如已经运行了HUNG_TASK_LOCK_BREAK时间，调用rcu_lock_break() 短暂退出rcu临界区并调度出去，避免一次rcu grace period的时间过长，之后再调度回来时再次进入rcu临界区。由于调度出去再回来时，正在检测的task可能已经释放，所以在调度出去之前，需要使用get_task_struct增加task的task_struct结构体的引用计数，防止其被释放，在通过pid_alive判断task是否dead后，再调用put_task_struct减小引用计数。如果调度回来时发现task已经dead，则退出本轮hung check。
C. 为符合GKI规范，此处通过vendor hook函数，调用vendor实现的hook函数，这里的实现是调用register函数注册对应hook函数，qcom_before_check_tasks() 和qcom_check_tasks_done()，后面会有分析，主要就是判断该task是否需要hungtask检查，并获得当前iowait task的数量。
vendor hook函数注册如下所示：
drivers\soc\qcom\hung_task_enh.c
D. 根据C处返回的need_check，如判断需要进行hungtask检查，则调用check_hung_task()，后面会有分析。
E. 此处调用qcom_check_tasks_done，判断在对所有task进行hung_task_enh.max_iowait_timeout_cnt轮的检测，如果连续地每轮都有大于等于hung_task_enh.max_iowait_task_cnt数量的task处于iowait状态，则直接触发panic。
F. 之后的流程就是在本轮hungtask检测结束后，跟踪标志状态显示task的锁状态及当前各CPU上的栈。
接下来看下hook函数的具体内容。
drivers\soc\qcom\hung_task_enh.c
A. 一个task根据其task_struct中的walt_task_struct的hung_detect_status成员判断，如果在白名单（白名单模式）或不在黑名单（黑名单模式），则置need_check标志，然后继续判断是否要增加iowait task数量的统计值。
B. 如果task处于iowait状态，且为D状态、暂停状态、跟踪状态之一，且到了检查hungtask的时间，且为用户空间进程主线程，则增加iowait task数量的统计值。
接下来看check_hung_task()的具体内容。
A. 如果task已冻结或为调用vfork的进程（会处于D状态直到等子进程调用exit或exec）则跳过hungtask检查。
B. task的自愿（nvcsw ）和非自愿（nivcsw）上下文切换次数的和如果在检测interval之间变动过，则说明该task没有hung住，即使task当前为D状态。直接返回，跳过该task。
C. 打印sysctl_hung_task_warnings次task block信息后就不再打印，也就是说，更多的hungtask信息有可能不会再被看到。打印task block信息时，会置hung_task_show_lock和hung_task_show_all_bt标志，在退出本轮所有task的hungtask检查后，会根据这些标志打印task的锁情况以及各CPU的backtrace。之后就退出了本轮的所有task的hungtask检查。
2.只关注重要进程
这里对第二种hungtask detect实现方式进行分析，只判断系统中的重要进程是否卡住，代码见参考文档2，主要涉及驱动代码：
drivers\misc\mediatek\monitor_hang\hang_detect.c
KCONFIG定义
drivers\misc\mediatek\monitor_hang\Kconfig （对应hung_task.c ）
代码分析
drivers\misc\mediatek\monitor_hang\hang_detect.c
A. 注册hang monitor的misc device，名称为RT_Monitor，通过其write接口控制hang monitor的使能，通过ioctl设置（类似watchdog kick操作）hang_detect_counter（后面分析的hang_detect线程会定时递减这个counter，也就是说，如果不重置，一定时间之后就会认为重要任务 hang住了）和hang monitor的使能（hd_detect_enabled）。
B. 启动hang_detect和hang_detect1线程。hang_detect线程为检测线程，下面分析。hang_detect1用来在检测到hang时dump系统状态。
继续看下hang_detect线程的工作。
A处启动循环，当hang detect使能，且白名单中的task均在系统中时，每HD_INTER秒（默认为30秒）会对hang_detect_counter减一，减一前会检查hang_detect_counter，当小于等于0时，会dump系统状态或触发BUG死机。
当系统持续hang住时，hang_detect_counter会先减到0，这时Hang_first_done是false（表示hang后的第一次处理还没完成），所以会运行wake_up_dump()（hang_detect线程）唤醒hang_detect1线程，hang_detect1线程dump系统状态之后，置dump_bt_done为1，表示已经完成dump backtrace，再唤醒wake_up_dump()（hang_detect线程），之后E处设置Hang_first_done为true，表示hang后的第一次处理已经完成，之后hang_detect_counter会减到-1。
若系统还持续hang住，会走到B处，此处判断条件时的意思是，如果之前hang_detect1线程dump系统状态没有正常执行完成，则这里会再启动hang_detect2；否则，还会再唤醒hang_detect1线程，再次dump系统状态，方便和之前的进行对比。之后走到D处，调用BUG触发死机重启以复位系统，否则关键进程可能一直卡住而不能自动恢复。
wake_up_dump()
hang_detect1线程
hang_detect2线程
篇幅有限 下文继续讲解
原文作者：内核工匠
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
