workqueue: Don't hold any lock while rcuwait'ing for !POOL_MANAGER_ACTIVE
authorValentin Schneider <vschneid@redhat.com>
Thu, 12 Jan 2023 16:14:30 +0000 (16:14 +0000)
committerTejun Heo <tj@kernel.org>
Thu, 12 Jan 2023 16:21:49 +0000 (06:21 -1000)
commit9ab03be42b8f9136dcc01a90ecc9ac71bc6149ef
treee5b48366114de8217d372ebfcd60089812f7ddb0
parent3f959aa3b33829acfcd460c6c656d54dfebe8d1e
workqueue: Don't hold any lock while rcuwait'ing for !POOL_MANAGER_ACTIVE

put_unbound_pool() currently passes wq_manager_inactive() as exit condition
to rcuwait_wait_event(), which grabs pool->lock to check for

  pool->flags & POOL_MANAGER_ACTIVE

A later patch will require destroy_worker() to be invoked with
wq_pool_attach_mutex held, which needs to be acquired before
pool->lock. A mutex cannot be acquired within rcuwait_wait_event(), as
it could clobber the task state set by rcuwait_wait_event()

Instead, restructure the waiting logic to acquire any necessary lock
outside of rcuwait_wait_event().

Since further work cannot be inserted into unbound pwqs that have reached
->refcnt==0, this is bound to make forward progress as eventually the
worklist will be drained and need_more_worker(pool) will remain false,
preventing any worker from stealing the manager position from us.

Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Valentin Schneider <vschneid@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
kernel/workqueue.c