【io_schedule】引发的hang detect 触发watchdog 重启

问题现象:机器发生hang detect watchdog 重启

版本信息:android R,linux-4.14

配置信息:UFS

机器发生Hang_detect，通过Log 分析：
1.Hang_detect count=12，表示监测到有线程30秒超时时设定的超时计数值
2.kernel log 可以看到 hang_detect count 12 -> 0 ，始终没有重新初始化，说明上层watchdog 基本上已经卡死：
   Line 1278: [16837.218359] (1)[259:hang_detect][Hang_Detect] hang_detect thread counts down 1:12, status 1.
   Line 1278: [16837.218359] (1)[259:hang_detect][Hang_Detect] hang_detect thread counts down 1:12, status 1.
   Line 1715: [16867.938310] (1)[259:hang_detect][Hang_Detect] hang_detect thread counts down 0:12, status 1.
   Line 1715: [16867.938310] (1)[259:hang_detect][Hang_Detect] hang_detect thread counts down 0:12, status 1.
   Line 1715: [16867.938310] (1)[259:hang_detect][Hang_Detect] hang_detect thread counts down 0:12, status 1.

3.检查watchdog 进程信息：
ppid=1135 pid=1248 D cpu=1 prio=120 wait=409s watchdog
本地调用栈:
   vmlinux __switch_to(prev=0xFFFFFFDD29C1EAC0, next=0xFFFFFFDD63132DC0) + 308 <arch/arm64/kernel/process.c:510>
   vmlinux context_switch(rq=0xFFFFFFDD7FE86900, prev=0xFFFFFFDD29C1EAC0, next=0xFFFFFFDD63132DC0, rf=0xFFFFFF8016493B08) + 664 <kernel/sched/core.c:4109>
   vmlinux __schedule(preempt=false) + 3852 <kernel/sched/core.c:4724>
   vmlinux schedule() + 96 <kernel/sched/core.c:4768>
   vmlinux io_schedule() + 140 <kernel/sched/core.c:6431>
   vmlinux wait_on_page_bit_common() + 440 <mm/filemap.c:1032>
   vmlinux __lock_page(__page=0xFFFFFFBF72000700) + 76 <mm/filemap.c:1210>
   vmlinux lock_page(page=0xFFFFFFBF72000700) + 48 <include/linux/pagemap.h:494>
   vmlinux __get_node_page(sbi=0xFFFFFFDD4FA4C000, nid=126, parent=0, start=0) + 228 <fs/f2fs/node.c:1364>
   vmlinux f2fs_get_node_page() + 8 <fs/f2fs/node.c:1397>
   vmlinux f2fs_read_inline_dir(file=0xFFFFFFDCFA5CCC00, ctx=0xFFFFFF8016493E50, fstr=0xFFFFFF8016493D60) + 188 <fs/f2fs/inline.c:734>
   vmlinux f2fs_readdir(file=0xFFFFFFDCFA5CCC00, ctx=0xFFFFFF8016493E50) + 528 <fs/f2fs/dir.c:1082>
   vmlinux iterate_dir(file=0xFFFFFFDCFA5CCC00, ctx=0xFFFFFF8016493E50) + 216 <fs/readdir.c:0>
   vmlinux SYSC_getdents64(count=4200) + 156 <fs/readdir.c:355>
   vmlinux SyS_getdents64() + 188 <fs/readdir.c:336>
   vmlinux 0xFFFFFF88F6C84814() <arch/arm64/kernel/entry.S:1020>
   == 栈结束 ==

watchdog 同样卡在了wait_on_page_bit_common 的io_schedule

想要进一步分析root cause

从你提供的信息来看，这是一个Linux系统上的hang detect问题，可能由IO调度、 watchdog进程或内核调度引起。以下是一些可能的解决方案和进一步调查的建议：

1.检查内核日志：内核日志中可能包含更多关于hang detect的信息，这可能有助于理解问题的根本原因。可以使用命令dmesg来查看内核日志。
2.检查IO调度：你提到UFS配置，UFS可能使用了复杂的IO调度策略。检查系统是否使用了适当的IO调度策略，并确保它适合你的工作负载。
3.检查watchdog进程：在watchdog进程调用栈中，wait=409s表示该进程在等待某个事件发生。这可能是导致hang detect的原因。检查这个等待事件是什么，并尝试找出为什么这个进程会阻塞。
4.使用调试工具：如果可能的话，开启内核调试模式（例如通过设置echo 1 > /proc/sys/kernel/panic_on_oops），这样在内核发生问题时，系统会立即重启，而不是简单地hang住。
5.收集更多信息：你可以尝试使用一些工具，如strace、gdb等来进一步调查问题。例如，使用strace -p -e trace=all可以跟踪该进程的所有系统调用。
6.更新内核和驱动程序：确保你的内核和驱动程序是最新的稳定版本，因为一些问题可能已经在后续的版本中得到修复。