Hungtask

1 前言

hungtask表现为某些重要进程一直不能运行，如长期处于uninterruptible sleep状态（也就是常说的D状态。可以采取多种方法检测：定时轮询系统中的所有task，然后判断处于D状态的task的上下文切换次数是否和之前轮询时的相等，如果相等则表明该task两个轮询间隔期间一直处于D状态，可以认为该task有hang的情况；或只关注重要进程的运行情况，让这个重要进程在规定时间内模拟喂狗操作，若发现没有及时喂狗，则认为其有hang的情况。

2 实现原理

内核的hung_task机制主要实现在kernel/hung_task.c文件中。实现原理为创建一个内核线程(khungtaskd)，定期(120秒)唤醒后，遍历系统中的所有进程，检查是否存在处于D状态超过120s(时长可以设置)的进程，如果存在，则打印相关警告和进程堆栈。如果配置了hung_task_panic（proc或内核启动参数），则直接发起panic。

/*
 * kthread which checks for tasks stuck in D state
 */
static int watchdog(void *dummy)
{
	unsigned long hung_last_checked = jiffies;

	set_user_nice(current, 0);

	for ( ; ; ) {
		unsigned long timeout = sysctl_hung_task_timeout_secs;
		unsigned long interval = sysctl_hung_task_check_interval_secs;
		long t;

		if (interval == 0)
			interval = timeout;
		interval = min_t(unsigned long, interval, timeout);
		t = hung_timeout_jiffies(hung_last_checked, interval);
		if (t <= 0) {
			if (!atomic_xchg(&reset_hung_task, 0) &&
			    !hung_detector_suspended)
				check_hung_uninterruptible_tasks(timeout);
			hung_last_checked = jiffies;
			continue;
		}
		schedule_timeout_interruptible(t);
	}

	return 0;
}

3 案例

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

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

产生hungtask的直接原因是所关注的task长时间处于D状态或无法调度运行，task本身有异常或系统有异常影响到了该task：对于系统异常，常见的可能原因有内存不足、内存分配异常、UFS器件异常、文件系统异常、spinlock或rwsem等各种锁死锁、中断风暴等等；task本身的异常，为其本身逻辑问题。

分析思路：
1.看hungtask报错前是否有异常打印，比如中断风暴检测的异常打印、rcu stall异常打印等。
2.查看运行队列上是否有高优先级rt进程持续占据cpu。
3.如果hungtask的进程在等锁，要看拿锁的owner在执行什么操作，是否有死锁的情况。
4.查看系统内存的使用情况，是否有内存泄漏或内存回收参数不合适导致内存不足。
5.块设备和文件系统异常也是常见的原因，有一部分原因也是内存不足导致。
6.判断是否task本身的异常，也可根据出问题时间点排除合入的patch。

参考:
Hungtask原理及分析
内核调试之hung_task机制及案例分析