summaryrefslogtreecommitdiffstats
path: root/kernel/workqueue.c
diff options
context:
space:
mode:
authorLai Jiangshan2013-02-19 21:17:02 +0100
committerTejun Heo2013-03-04 18:44:58 +0100
commitb31041042a8cdece67f925e4bae55b5f5fd754ca (patch)
tree6392271c537c05d59e0d72ac72463343d2a29249 /kernel/workqueue.c
parentworkqueue: change argument of worker_maybe_bind_and_lock() to @pool (diff)
downloadkernel-qcow2-linux-b31041042a8cdece67f925e4bae55b5f5fd754ca.tar.gz
kernel-qcow2-linux-b31041042a8cdece67f925e4bae55b5f5fd754ca.tar.xz
kernel-qcow2-linux-b31041042a8cdece67f925e4bae55b5f5fd754ca.zip
workqueue: better define synchronization rule around rescuer->pool updates
Rescuers visit different worker_pools to process work items from pools under pressure. Currently, rescuer->pool is updated outside any locking and when an outsider looks at a rescuer, there's no way to tell when and whether rescuer->pool is gonna change. While this doesn't currently cause any problem, it is nasty. With recent worker_maybe_bind_and_lock() changes, we can move rescuer->pool updates inside pool locks such that if rescuer->pool equals a locked pool, it's guaranteed to stay that way until the pool is unlocked. Move rescuer->pool inside pool->lock. This patch doesn't introduce any visible behavior difference. tj: Updated the description. Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com> Signed-off-by: Tejun Heo <tj@kernel.org>
Diffstat (limited to 'kernel/workqueue.c')
-rw-r--r--kernel/workqueue.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 09545d445a55..fd9a28a13afd 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -2357,8 +2357,8 @@ repeat:
mayday_clear_cpu(cpu, wq->mayday_mask);
/* migrate to the target cpu if possible */
- rescuer->pool = pool;
worker_maybe_bind_and_lock(pool);
+ rescuer->pool = pool;
/*
* Slurp in all works issued via this workqueue and
@@ -2379,6 +2379,7 @@ repeat:
if (keep_working(pool))
wake_up_worker(pool);
+ rescuer->pool = NULL;
spin_unlock_irq(&pool->lock);
}