Hungtask原理及分析

发表于 2年以前 | 总阅读数：463 次

一、简介

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）

代码分析

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线程

三、问题分析

上面介绍了两种hungtask检测的原理及方法，我们知道了不同系统可以如何判断task已经hang住，进而触发系统去显示或保存现场状态（如发现重要task持续hang住时，会多次打印D状态task的栈信息、或系统最终因为hungtask无法恢复而重启时保存ramdump）及异常恢复。

一般可以通过kernel log中的task栈信息打印，看到hang住的关键task及其对应的栈，并对比相隔一定时间的多次该task的栈情况，明确该task确实已经异常，之后就可以根据栈的情况推测及寻找线索。如果开启了ramdump，异常重启时保存的ramdump也会对问题分析产生很大的帮助。

实际遇到的大多数问题，通过log中的task栈信息，一般只能粗略知道task hang住的大致现场及方向，还需要结合log中的其他信息、ramdump等进行分析，可能还需要判断问题发生场景、编译调试版本复现问题抓取更多信息，或者排查可疑修改。

由hungtask原理可知，产生hungtask异常的直接原因是所关注的task长时间处于D状态或无法调度运行，一般就是task本身有异常或系统有异常影响到了该task。以系统异常的情况居多，常见的可能原因有内存不足、内存分配异常、UFS器件异常、文件系统异常、spinlock或rwsem等各种锁死锁、中断风暴等等；task本身的异常，可能是其本身逻辑问题，需要具体分析。针对每种原因，大都有对应的判断及定位方法，可以输出相应的调试版本压测复现分析。

以下举两个实际的例子看下hungtask问题发生的现象及分析方法。

1、开关机测试时死机

在开关机测试及各项功能测试时均出现了低概率死机问题，由于故障机分散，判断为非硬件个体问题。查看故障机kernel log，发现死机之前，有hungtask打印。下面是其中一例死机前输出的hungtask情况。

hungtask检测输出的hang住的其中几个task的栈情况如下，该例中init进程阻塞在了io上。

分析多例故障现场，hang住的task不一致，用T32分析对应的ramdump，task会卡在对不同文件的io操作；出问题时hang住的task数量均较多。

解析ramdump得到cpu上的任务队列情况，

发现一个swr irq（音频功放注册的中断）在运行，一个swr irq在pending，还有多个cfs task也在pending。查看系统中断状态，观察到开机的短时间内，产生了大量中断，引起中断风暴，可能会严重影响系统中其他任务的执行，包括io操作，由此导致比较随机的开机时不同任务卡io的问题的发生。

之后去掉该音频功放注册的中断（实际上这个中断对应的音频功放并没有使用，中断引脚输入状态不定导致随机的中断异常），进行开关机压测，没有复现问题。

2、Monkey测试时死机

某项目发现低概率hungtask问题，过一段时间就会有一、两例出现，在Money测试中概率有所上升，每轮中能稳定出现一到两例。每次出现问题的task不一定相同。下面举一个例子：

这里时surfaceflinger出现了hungtask情况，其一直在尝试获取 kworker/u16:14 进程所持的mutex。再查看kworker/u16:14，

可以看到该task在等rpm（处理系统中时钟和电源请求的子系统）操作的completion，但这里rpm ack一直没有返回。查看其它异常时现场，共性都是rpm ack一直没有返回。最后分析到，虽然系统还有足够的H memory（HighAtomic），但ap和rpm通信用的glink分配内存时无法使用这种迁移类型的memory；系统同时有许多zs_malloc失败的情况，因为zram功能本身在进行内存分配时，也没有使用H memory，从而导致anon page回收异常。

最后，调整内存回收参数，该问题得以优化。

四、总结

本文主要描述了什么是hungtask、hungtask检测方法以及hungtask产生的原因，并通过两个案例，展示了具体问题分析方法。

hungtask表现为某些重要进程一直不能运行，如长期处于uninterruptible sleep状态（也就是常说的D状态。可以采取多种方法检测：定时轮询系统中的所有task，然后判断处于D状态的task的上下文切换次数是否和之前轮询时的相等，如果相等则表明该task两个轮询间隔期间一直处于D状态，可以认为该task有hang的情况；或只关注重要进程的运行情况，让这个重要进程在规定时间内模拟喂狗操作，若发现没有及时喂狗，则认为其有hang的情况。产生hungtask的直接原因是所关注的task长时间处于D状态或无法调度运行，task本身有异常或系统有异常影响到了该task：对于系统异常，常见的可能原因有内存不足、内存分配异常、UFS器件异常、文件系统异常、spinlock或rwsem等各种锁死锁、中断风暴等等；task本身的异常，为其本身逻辑问题。

参考文档

1. https://github.com/oppo-source/android_kernel_5.10_oppo_mt6983

2. https://github.com/OnePlusOSS/android_kernel_msm-5.10_oneplus_sm8450