Linux内核中的奇怪死锁答案

【问题标题】：Strange deadlock in Linux kernelLinux内核中的奇怪死锁
【发布时间】：2015-03-04 02: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 写入）。谁能解释一下为什么这是一个死锁场景？

【问题讨论】：

显示整个消息。
什么是tell_me_store 和lock_irq_serial？ Linux内核中没有这样的东西。此外，关于“获取两个不同的锁” - 没有必要。死锁可能包括 N 线程和 M 锁，2 线程和 2 锁只是最简单的情况。
尝试在内核中启用lockdep 功能。它应该向您显示更具体的消息（在运行时）。您还可以在可疑来源上运行 coccicheck 以检测死锁。

标签： c linux linux-kernel deadlock irq

【解决方案1】：

死锁可能发生在单核中。

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

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

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

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

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

【讨论】：