Question

我通常认为死锁可能是在两个不同线程（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写入）。任何人都可以解释为什么这是一个死锁场景？

Answer 1

死锁可以在单核中发生。

1）正常的内核上下文正在进行“spin_lock”

2）中断处理程序采用相同的“spin_lock”。

然后，当内核上下文持有锁时，如果中断到来，会发生什么？不一定是多个锁和多个线程。（实际上，涉及多个上下文。）

通过查看回溯，很难理解发生了什么。通常情况下，在死锁情况下的回溯不会显示谁持有锁。

建议是，启用内核死锁检测配置选项，看看会发生什么。

Linux内核中的奇怪死锁

1 个答案: