[lkml]   [2011]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[patch 09/38] workqueue: fix deadlock in worker_maybe_bind_and_lock()
2.6.38-stable review patch.  If anyone has any objections, please let us know.


From: Tejun Heo <>

commit 5035b20fa5cd146b66f5f89619c20a4177fb736d upstream.

If a rescuer and stop_machine() bringing down a CPU race with each
other, they may deadlock on non-preemptive kernel. The CPU won't
accept a new task, so the rescuer can't migrate to the target CPU,
while stop_machine() can't proceed because the rescuer is holding one
of the CPU retrying migration. GCWQ_DISASSOCIATED is never cleared
and worker_maybe_bind_and_lock() retries indefinitely.

This problem can be reproduced semi reliably while the system is
entering suspend.

A lot of kudos to Thilo-Alexander for reporting this tricky issue and
painstaking testing.

stable: This affects all kernels with cmwq, so all kernels since and
including v2.6.36 need this fix.

Signed-off-by: Tejun Heo <>
Reported-by: Thilo-Alexander Ginkel <>
Tested-by: Thilo-Alexander Ginkel <>
Signed-off-by: Greg Kroah-Hartman <>

kernel/workqueue.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1283,8 +1283,14 @@ __acquires(&gcwq->lock)
return true;

- /* CPU has come up inbetween, retry migration */
+ /*
+ * We've raced with CPU hot[un]plug. Give it a breather
+ * and retry migration. cond_resched() is required here;
+ * otherwise, we might deadlock against cpu_stop trying to
+ * bring down the CPU on non-preemptive kernel.
+ */
+ cond_resched();

 \ /
  Last update: 2011-05-06 02:21    [W:0.130 / U:26.040 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site