Linux内核中的奇怪死锁
Linux内核中的奇怪死锁
提问于 2015-03-04 10:26:08
我通常认为死锁可能是在两个不同的线程(CPU)上获取两个不同的锁，同时彼此持有另一个锁的冲突。
但是，linux内核中的lockdep告诉我并非如此：
这里是第一个：
[ 340.052197] [<ffffffff81405448>] lock_irq_serial+0x14/0x16
[ 340.058529] [<ffffffff8136cb7e>] tell_me_store+0x178/0x60a
[ 340.064858] [<ffffffff8136a9be>] kobj_attr_store+0xf/0x19
[ 340.070641] [<ffffffff811e0d55>] sysfs_kf_write+0x39/0x3b
[ 340.076423] [<ffffffff811e01ee>] kernfs_fop_write+0xd5/0x11e
[ 340.082475] [<ffffffff81188c0d>] vfs_write+0xb7/0x18f
[ 340.087890] [<ffffffff81189470>] SyS_write+0x42/0x86
[ 340.093213] [<ffffffff816eff79>] ia32_do_call+0x13/0x13其中lock_irq_serial是一个spin_lock。这个锁也在irq_work基础设施中使用。
另一部分是：
[ 344.135856] [<ffffffff8110be77>] generic_exec_single+0x108/0x120
[ 344.142277] [<ffffffff8109071e>] ? leave_mm+0xbc/0xbc
[ 344.147691] [<ffffffff8109071e>] ? leave_mm+0xbc/0xbc
[ 344.153104] [<ffffffff8109071e>] ? leave_mm+0xbc/0xbc
[ 344.158525] [<ffffffff8110bf46>] smp_call_function_single+0x88/0xa4
[ 344.165225] [<ffffffff8110c0ff>] smp_call_function_many+0xf7/0x21a
[ 344.171829] [<ffffffff8109071e>] ? leave_mm+0xbc/0xbc
[ 344.177249] [<ffffffff810908a2>] native_flush_tlb_others+0x29/0x2b
[ 344.183853] [<ffffffff81090a4a>] flush_tlb_mm_range+0xed/0x146
[ 344.190094] [<ffffffff811769fc>] change_protection+0x126/0x581
[ 344.196336] [<ffffffff81176fa9>] mprotect_fixup+0x152/0x1cb
[ 344.202299] [<ffffffff811771a1>] SyS_mprotect+0x17f/0x20e
[ 344.208078] [<ffffffff816eff79>] ia32_do_call+0x13/0x13在那里我什么都不做。我认为irq_work中的自旋锁定和其他地方的锁定(比如sysfs编写)可能会有问题。有没有人能进一步解释为什么这是一个死锁的场景？
回答 1
Stack Overflow用户
发布于 2015-03-05 02:51:08
死锁可能发生在单核中。
1)正常的内核上下文采用"spin_lock“
2)中断处理程序采用相同的"spin_lock“。
然后，当内核上下文持有锁时，如果中断到来，会发生什么？不一定是多个锁和多个线程。(实际上，使用了多个上下文。)
通过查看回溯，很难理解发生了什么。通常，死锁情况下的回溯不会显示谁持有锁。
建议启用内核死锁检测配置选项，看看会发生什么。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/28845663
复制相关文章
相似问题
腾讯云开发者
