diff options
authorLai Jiangshan <laijs@cn.fujitsu.com>2012-09-18 10:40:00 -0700
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2013-08-29 09:50:11 -0700
commit31eafff4382b0f20edce1afea8e2d288c6c7187c (patch)
parent67db9db0bfd9448feb8e69224dfbb83e5834082b (diff)
workqueue: fix possible stall on try_to_grab_pending() of a delayed work item
commit 3aa62497594430ea522050b75c033f71f2c60ee6 upstream. Currently, when try_to_grab_pending() grabs a delayed work item, it leaves its linked work items alone on the delayed_works. The linked work items are always NO_COLOR and will cause future cwq_activate_first_delayed() increase cwq->nr_active incorrectly, and may cause the whole cwq to stall. For example, state: cwq->max_active = 1, cwq->nr_active = 1 one work in cwq->pool, many in cwq->delayed_works. step1: try_to_grab_pending() removes a work item from delayed_works but leaves its NO_COLOR linked work items on it. step2: Later on, cwq_activate_first_delayed() activates the linked work item increasing ->nr_active. step3: cwq->nr_active = 1, but all activated work items of the cwq are NO_COLOR. When they finish, cwq->nr_active will not be decreased due to NO_COLOR, and no further work items will be activated from cwq->delayed_works. the cwq stalls. Fix it by ensuring the target work item is activated before stealing PENDING in try_to_grab_pending(). This ensures that all the linked work items are activated without incorrectly bumping cwq->nr_active. tj: Updated comment and description. Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com> Signed-off-by: Tejun Heo <tj@kernel.org> [lizf: backported to 3.4: adjust context] Signed-off-by: Li Zefan <lizefan@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1 files changed, 22 insertions, 3 deletions
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index a64b94e3c27c..9a0b579c40cf 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -1721,10 +1721,9 @@ static void move_linked_works(struct work_struct *work, struct list_head *head,
*nextp = n;
-static void cwq_activate_first_delayed(struct cpu_workqueue_struct *cwq)
+static void cwq_activate_delayed_work(struct work_struct *work)
- struct work_struct *work = list_first_entry(&cwq->delayed_works,
- struct work_struct, entry);
+ struct cpu_workqueue_struct *cwq = get_work_cwq(work);
struct list_head *pos = gcwq_determine_ins_pos(cwq->gcwq, cwq);
@@ -1733,6 +1732,14 @@ static void cwq_activate_first_delayed(struct cpu_workqueue_struct *cwq)
+static void cwq_activate_first_delayed(struct cpu_workqueue_struct *cwq)
+ struct work_struct *work = list_first_entry(&cwq->delayed_works,
+ struct work_struct, entry);
+ cwq_activate_delayed_work(work);
* cwq_dec_nr_in_flight - decrement cwq's nr_in_flight
* @cwq: cwq of interest
@@ -2625,6 +2632,18 @@ static int try_to_grab_pending(struct work_struct *work)
if (gcwq == get_work_gcwq(work)) {
+ /*
+ * A delayed work item cannot be grabbed directly
+ * because it might have linked NO_COLOR work items
+ * which, if left on the delayed_list, will confuse
+ * cwq->nr_active management later on and cause
+ * stall. Make sure the work item is activated
+ * before grabbing.
+ */
+ if (*work_data_bits(work) & WORK_STRUCT_DELAYED)
+ cwq_activate_delayed_work(work);