Files
kernel-eswin-eic7700/include/linux
John Stultz db751fe3ea cpuset: Fix potential deadlock w/ set_mems_allowed
After adding lockdep support to seqlock/seqcount structures,
I started seeing the following warning:

[    1.070907] ======================================================
[    1.072015] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
[    1.073181] 3.11.0+ #67 Not tainted
[    1.073801] ------------------------------------------------------
[    1.074882] kworker/u4:2/708 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[    1.076088]  (&p->mems_allowed_seq){+.+...}, at: [<ffffffff81187d7f>] new_slab+0x5f/0x280
[    1.077572]
[    1.077572] and this task is already holding:
[    1.078593]  (&(&q->__queue_lock)->rlock){..-...}, at: [<ffffffff81339f03>] blk_execute_rq_nowait+0x53/0xf0
[    1.080042] which would create a new lock dependency:
[    1.080042]  (&(&q->__queue_lock)->rlock){..-...} -> (&p->mems_allowed_seq){+.+...}
[    1.080042]
[    1.080042] but this new dependency connects a SOFTIRQ-irq-safe lock:
[    1.080042]  (&(&q->__queue_lock)->rlock){..-...}
[    1.080042] ... which became SOFTIRQ-irq-safe at:
[    1.080042]   [<ffffffff810ec179>] __lock_acquire+0x5b9/0x1db0
[    1.080042]   [<ffffffff810edfe5>] lock_acquire+0x95/0x130
[    1.080042]   [<ffffffff818968a1>] _raw_spin_lock+0x41/0x80
[    1.080042]   [<ffffffff81560c9e>] scsi_device_unbusy+0x7e/0xd0
[    1.080042]   [<ffffffff8155a612>] scsi_finish_command+0x32/0xf0
[    1.080042]   [<ffffffff81560e91>] scsi_softirq_done+0xa1/0x130
[    1.080042]   [<ffffffff8133b0f3>] blk_done_softirq+0x73/0x90
[    1.080042]   [<ffffffff81095dc0>] __do_softirq+0x110/0x2f0
[    1.080042]   [<ffffffff81095fcd>] run_ksoftirqd+0x2d/0x60
[    1.080042]   [<ffffffff810bc506>] smpboot_thread_fn+0x156/0x1e0
[    1.080042]   [<ffffffff810b3916>] kthread+0xd6/0xe0
[    1.080042]   [<ffffffff818980ac>] ret_from_fork+0x7c/0xb0
[    1.080042]
[    1.080042] to a SOFTIRQ-irq-unsafe lock:
[    1.080042]  (&p->mems_allowed_seq){+.+...}
[    1.080042] ... which became SOFTIRQ-irq-unsafe at:
[    1.080042] ...  [<ffffffff810ec1d3>] __lock_acquire+0x613/0x1db0
[    1.080042]   [<ffffffff810edfe5>] lock_acquire+0x95/0x130
[    1.080042]   [<ffffffff810b3df2>] kthreadd+0x82/0x180
[    1.080042]   [<ffffffff818980ac>] ret_from_fork+0x7c/0xb0
[    1.080042]
[    1.080042] other info that might help us debug this:
[    1.080042]
[    1.080042]  Possible interrupt unsafe locking scenario:
[    1.080042]
[    1.080042]        CPU0                    CPU1
[    1.080042]        ----                    ----
[    1.080042]   lock(&p->mems_allowed_seq);
[    1.080042]                                local_irq_disable();
[    1.080042]                                lock(&(&q->__queue_lock)->rlock);
[    1.080042]                                lock(&p->mems_allowed_seq);
[    1.080042]   <Interrupt>
[    1.080042]     lock(&(&q->__queue_lock)->rlock);
[    1.080042]
[    1.080042]  *** DEADLOCK ***

The issue stems from the kthreadd() function calling set_mems_allowed
with irqs enabled. While its possibly unlikely for the actual deadlock
to trigger, a fix is fairly simple: disable irqs before taking the
mems_allowed_seq lock.

Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Li Zefan <lizefan@huawei.com>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Link: http://lkml.kernel.org/r/1381186321-4906-4-git-send-email-john.stultz@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2013-11-06 12:40:27 +01:00
..
2013-08-14 13:55:15 +05:30
2013-06-17 14:38:54 -04:00
2013-07-30 11:53:12 -04:00
2013-05-29 15:50:34 -04:00
2013-07-03 16:07:39 -07:00
2013-08-26 18:40:56 -04:00
2013-08-27 01:44:40 +02:00
2013-05-01 16:36:22 +05:30
2013-07-23 16:01:28 -07:00
2013-07-15 11:25:00 +09:30
2013-05-07 18:38:27 -07:00
2013-04-29 18:28:40 -07:00
2013-08-26 20:15:23 +09:00
2013-06-17 16:38:57 -07:00
2013-08-22 22:13:54 -07:00
2013-06-19 23:32:07 -04:00
2013-08-23 10:22:29 +02:00
2013-06-13 17:51:04 -07:00
2013-07-18 13:05:23 -07:00
2013-08-22 20:30:15 -07:00
2013-06-17 16:38:57 -07:00
2013-09-13 15:09:52 +02:00
2013-09-13 15:09:52 +02:00
2013-09-13 15:09:52 +02:00
2013-08-09 10:49:00 +02:00
2013-07-26 16:19:48 -07:00
2013-04-30 17:04:06 -07:00
2013-08-28 21:35:14 -07:00
2013-07-16 22:00:14 -07:00
2013-05-31 00:48:22 -07:00
2013-09-26 11:03:29 +02:00
2013-08-12 15:27:01 +00:00
2013-09-08 20:20:23 -04:00
2013-07-03 16:08:05 -07:00
2013-06-08 16:20:14 -04:00
2013-05-04 14:47:26 -04:00
2013-09-03 16:40:32 -04:00
2013-09-24 21:12:32 -05:00
2013-08-12 15:27:01 +00:00
2013-06-12 12:37:30 +01:00
2013-04-29 15:54:28 -07:00
2013-09-09 14:29:15 -07:00
2013-05-31 17:19:05 -07:00
2013-06-21 11:32:51 +02:00
2013-07-03 16:08:05 -07:00
2013-11-01 08:24:41 +01:00
2013-06-17 16:38:57 -07:00
2013-06-17 18:09:53 +09:00
2013-09-10 18:56:32 -04:00
2013-09-04 23:11:42 +03:00
2013-04-30 15:50:12 +05:30
2013-09-12 15:38:02 -07:00
2013-05-21 12:25:02 -05:00
2013-08-05 10:52:36 -06:00
2013-05-27 10:57:53 +09:00
2013-10-17 15:53:09 -04:00
2013-07-10 18:11:34 -07:00