0

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

4

1 回答 1

0

死锁可能发生在单核中。

1) 正常内核上下文采用“spin_lock”

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

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

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

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

于 2015-03-04T18:51:08.017 回答