系统终端输出 “watchdog：BUG：soft lockup - CPU#21” __fsnotify_update_child_dentry_flags

1. 故障概述
   • 故障现象：系统终端出现 “watchdog：BUG：soft lockup - CPU#21” 等报警信息，表明系统在运行过程中出现了软锁死现象，且影响到了 CPU#21。
   • 故障时间：根据日志记录，故障发生在特定的时间点，具体时间可参考相关日志信息。
2. 故障分析
   • 内核信息
     • 函数调用链路：通过对内核日志的分析，发现 soft lockup 时的调用链路为inotify_add_watch -> entry_SYSCALL_64_after_hwframe -> do_syscall_64 -> x64_sys_inotify_add_watch -> inotify_update_watch -> fsnotify_add_mark_locked -> fsnotify_update_child_dentry_flags，该链路表明问题可能出现在文件监控的fsnotify机制中。
     • 关键函数分析
       • __fsnotify_update_child_dentry_flags函数：在该函数内部，通过遍历目录的dentry来更新子目录的标志位。在某些情况下，如目录下存在大量的无效dentry（negative dentry），可能会导致函数执行耗时过长，从而引发软锁死。
       • spin_lock操作：在__fsnotify_update_child_dentry_flags函数中，使用了spin_lock(&inode->i_lock)来获取锁，若某个进程长时间持有该锁，其他进程在尝试获取锁时会导致自旋等待，消耗大量 CPU 资源，可能导致软锁死。
   • 系统环境
     • 硬件资源：服务器的硬件配置可能会影响系统的性能和稳定性。例如，CPU 的性能、内存大小等因素可能与软锁死问题有关。
     • 软件环境
       • 内核版本：不同版本的内核在文件监控机制的实现上可能存在差异，可能会导致一些潜在的问题。
       • 文件系统：文件系统的特性和配置也可能对文件监控产生影响。例如，dentry cache 的管理方式、inode 的使用情况等。
   • 业务场景
     • 文件监控操作：根据日志描述，业务场景中涉及到对特定目录的频繁文件创建和删除操作，如在/path/to/problem目录中创建随机文件名的文件然后删除，且频繁重复这一动作。这种操作可能会导致目录下的dentry数量增加，尤其是大量的negative dentry，从而影响文件监控的性能和稳定性。
     • 监控范围变化：文件监控服务的监控范围发生了变更，可能导致对某些目录的监控增加，进而引发了软锁死问题。
3. 问题解决思路
   • 临时解决措施
     • 清理缓存：通过执行echo 2 > /proc/sys/vm/drop_caches命令清空dentry cache，可以暂时解决软锁死问题。但该操作可能会影响系统性能，应作为应急方案使用。
   • 长期解决措施
     • 监控目标取舍：在文件监控服务中，应根据业务情况对监控目标进行取舍，避免对某些频繁进行文件创建和删除操作的目录进行监控，将其加入黑名单。
     • 优化文件监控逻辑
       • 减少遍历：优化__fsnotify_update_child_dentry_flags函数的遍历逻辑，避免对大量无效dentry进行不必要的操作，减少函数执行时间。
       • 锁管理：确保spin_lock的正确使用，避免进程长时间持有锁，导致其他进程无法获取锁而出现自旋等待。
4. 总结
   • 本次故障是由于文件监控过程中fsnotify机制的某些问题导致的，主要与dentry管理和spin_lock使用有关。通过对内核日志和函数调用链路的分析，定位了问题的根源，并提出了相应的解决思路。
   • 在实际应用中，应注意监控业务的特点，合理配置文件监控参数，避免出现类似的问题。同时，对于 Linux 系统的内核机制应有深入的了解，以便更好地解决系统运行中出现的各种问题。