Files
odroid-linux/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-03-01 13:39:00 -08:00
2013-06-17 14:38:54 -04:00
2013-07-30 11:53:12 -04:00
2013-05-29 15:50:34 -04:00
2012-10-08 13:50:20 +10:30
2012-12-02 00:05:12 +00: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-03-12 11:30:04 -07:00
2013-05-01 16:36:22 +05:30
2012-09-30 18:02:20 -07:00
2013-07-23 16:01:28 -07:00
2012-10-16 18:49:15 -07:00
2013-02-26 02:46:08 -05:00
2013-07-15 11:25:00 +09:30
2013-05-07 18:38:27 -07:00
2013-03-15 15:09:43 +10:30
2013-04-29 18:28:40 -07:00
2012-11-22 13:43:27 +09: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
2012-11-08 16:58:30 +01:00
2013-01-25 21:03:54 -08: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-04-01 11:04:50 -07:00
2012-10-10 01:15:44 -04: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
2012-12-11 17:22:27 -08: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
2012-10-10 22:41:05 -04:00
2012-07-10 10:32:06 -05:00
2013-08-12 15:27:01 +00:00
2013-06-12 12:37:30 +01:00
2012-07-31 18:42:43 -07: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-04-12 10:26:23 +02:00
2013-07-03 16:08:05 -07:00
2012-10-06 03:05:01 +09: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
2012-08-21 16:28:31 +02:00
2012-10-09 16:22:32 +09:00
2013-05-21 12:25:02 -05:00
2012-07-22 23:57:55 +04:00
2013-03-20 12:10:38 -04: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