xavi/android_kernel_m2note/kernel/workqueue.c, branch o-8.1

workqueue: allow work_on_cpu() to be called recursively

2017-12-05T17:08:35+00:00

If the @fn call work_on_cpu() again, the lockdep will complain: > [ INFO: possible recursive locking detected ] > 3.11.0-rc1-lockdep-fix-a #6 Not tainted > --------------------------------------------- > kworker/0:1/142 is trying to acquire lock: > ((&wfc.work)){+.+.+.}, at: [] flush_work+0x0/0xb0 > > but task is already holding lock: > ((&wfc.work)){+.+.+.}, at: [] process_one_work+0x169/0x610 > > other info that might help us debug this: > Possible unsafe locking scenario: > > CPU0 > ---- > lock((&wfc.work)); > lock((&wfc.work)); > > *** DEADLOCK *** It is false-positive lockdep report. In this sutiation, the two "wfc"s of the two work_on_cpu() are different, they are both on stack. flush_work() can't be deadlock. To fix this, we need to avoid the lockdep checking in this case, thus we instroduce a internal __flush_work() which skip the lockdep. tj: Minor comment adjustment. Signed-off-by: Lai Jiangshan Reported-by: "Srivatsa S. Bhat" Reported-by: Alexander Duyck Signed-off-by: Tejun Heo

workqueue: move flush_scheduled_work() to workqueue.h

2017-12-05T17:08:32+00:00

flush_scheduled_work() is just a simple call to flush_work(). Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo

kernel/workqueue.c: pr_warning/pr_warn & printk/pr_info

2017-12-05T17:08:32+00:00

tj: Refreshed on top of wq/for-3.16. Cc: Andrew Morton Signed-off-by: Fabian Frederick Signed-off-by: Tejun Heo

workqueue: simplify wq_update_unbound_numa() by jumping to use_dfl_pwq if the target cpumask equals wq's

2017-12-05T17:08:31+00:00

wq_update_unbound_numa(), when it's decided that the newly updated cpumask equals the default, looks at whether the current pwq is already the default one and skips setting pwq to the default one. This extra step is unnecessary and we can always jump to use_dfl_pwq instead. Simplify the code by removing the conditional. This doesn't make any functional difference. Signed-off-by: Daeseok Youn Signed-off-by: Tejun Heo

workqueue: wake regular worker if need_more_worker() when rescuer leave the pool

2017-12-05T17:08:30+00:00

We don't need to wake up regular worker when nr_running==1, so need_more_worker() is sufficient here. And need_more_worker() gives us better readability due to the name of "keep_working()" implies the rescuer should keep working now but the rescuer is actually leaving. Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo

workqueue: alloc struct worker on its local node

2017-12-05T17:08:30+00:00

When the create_worker() is called from non-manager, the struct worker is allocated from the node of the caller which may be different from the node of pool->node. So we add a node ID argument for the alloc_worker() to ensure the struct worker is allocated from the preferable node. tj: @nid renamed to @node for consistency. Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo

workqueue: reuse the already calculated pwq in try_to_grab_pending()

2017-12-05T17:08:30+00:00

try_to_grab_pending() was re-calculating the associated pwq using get_work_pwq() when it already has it cached in a local varible and the association can't change. Reuse the local variable instead. This doesn't introduce any functional changes. tj: Updated description. Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo

workqueue: stronger test in process_one_work()

2017-12-05T17:08:29+00:00

When POOL_DISASSOCIATED is cleared, the running worker's local CPU should be the same as pool->cpu without any exception even during cpu-hotplug. This patch changes "(proposition_A && proposition_B && proposition_C)" to "(proposition_B && proposition_C)", so if the old compound proposition is true, the new one must be true too. so this won't hide any possible bug which can be hit by old test. tj: Minor description update and dropped the obvious comment. CC: Jason J. Herne CC: Sasha Levin Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo

workqueue: remove useless WARN_ON_ONCE()

2017-12-05T17:08:29+00:00

The @cpu is fetched via smp_processor_id() in this function, so the check is useless. Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo

workqueue: sanity check pool->cpu in wq_worker_sleeping()

2017-12-05T17:08:28+00:00

In theory, pool->cpu is equals to @cpu in wq_worker_sleeping() after worker->flags is checked. And "pool->cpu != cpu" sanity check will help us if something wrong. Signed-off-by: Lai Jiangshan Signed-off-by: Tejun Heo