记一次内核soft lockup的定位记录

最新推荐文章于 2025-03-21 10:42:59 发布

kklvsports

最新推荐文章于 2025-03-21 10:42:59 发布

阅读量1.8k

点赞数

分类专栏： Linux内核 Linux

本文链接：https://blog.youkuaiyun.com/kklvsports/article/details/77109520

版权

在大用户场景下，产品出现内核soft lockup错误，原因是CPU在获取读写锁时发生问题。通过分析内核代码和日志，排除了多锁操作顺序不当和链表过长的原因。发现锁获取后进行的kmalloc操作由于使用GFP_ATOMIC不会引起睡眠。启用内核的lockdep调试特性，重新编译内核后，发现在获取锁的任务被中断，且中断处理程序中又尝试获取锁，导致死锁。解决方案是改用关闭中断的read_lockirqsave和write_lockirqsave接口。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

产品大用户场景下运行一段时间即报“Aug 7 19:19:58 localhost kernel: NMI watchdog: BUG: soft lockup - CPU#7 stuck for 23s! [xxxx:80779]" 错误，内核日志调用栈显示是在获取锁时失败，该锁是读写锁，使用read_lock或者write_lock获取锁，锁使用情况如下所示，如图所示锁用在桶深256的HASH表下挂链表插入删除时的竞争保护。刚开始按照用户态经验加锁时锁不可用不是被挂起睡眠吗？等待锁可用再被唤醒，怎么会一直占有CPU20多秒，通过分析内核读写锁函数发现内核读写锁类似spin_lock死等，所以应该是该锁被其他人长时间占用，到了调用栈所示的调用时一直无法获取锁导致的，死等20多秒超时导致该CPU的watchdog发现（watchdog是IRQ所以不会因为死等锁而不能调度），同时可以确定用户态死锁不会导致soft lockup。