Re: [PATCH] cgroup/cpuset: fix circular locking dependency

[Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

Hello, Paul.

Sorry about the delay.  Travel followed by cold. :(

On Tue, Jan 02, 2018 at 10:01:19AM -0800, Paul E. McKenney wrote:
> Actually, after taking a quick look, could you please supply me with
> a way of mark a statically allocated workqueue as WQ_MEM_RECLAIM after
> the fact?  Otherwise, I end up having to check for the workqueue having

Hmmm... there is no statically allocated workqueue tho.  If you're
referring to the system-wide workqueues (system*_wq), they're just
created dynamically early during boot.

> been allocated pretty much each time I use it, which is going to be an
> open invitation for bugs.  Plus it looks like there are ways that RCU's
> workqueue wakeups can be executed during very early boot, which can be
> handled, but again in a rather messy fashion.
> 
> In contrast, given a way of mark a statically allocated workqueue
> as WQ_MEM_RECLAIM after the fact, I simply continue initializing the
> workqueue at early boot, and then add the WQ_MEM_RECLAIM marking some
> arbitrarily chosen time after the scheduler has been initialized.
> 
> The required change to workqueues looks easy, just move the body of
> the "if (flags & WQ_MEM_RECLAIM) {" statement in __alloc_workqueue_key()
> to a separate function, right?

Ah, okay, yes, currently, workqueue init is kinda silly in that while
it allows init of non-mem-reclaiming workqueues way before workqueue
is actually online, it doesn't allow the same for mem-reclaiming ones.
As you pointed out, it's just an oversight on my part as the init path
split was done initially to accomodate early init of system
workqueues.

I'll update the code so that rescuers can be added later too; however,
please note that while the work items may be queued, they won't be
executed until workqueue_init() is run (the same as now) as there
can't be worker threads anyway before that point.

Thanks.

-- 
tejun