Re: [PATCH] loop: add WQ_MEM_RECLAIM flag to per device workqueue

[Dave Chinner <david@fromorbit.com>]

On Wed, Mar 23, 2022 at 08:32:49AM +0900, Tetsuo Handa wrote:
> On 2022/03/23 7:59, Dave Chinner wrote:
> > I don't know what the solution is, but if the fix is "xfs needs to
> > mark a workqueue that has nothing to do with memory reclaim as
> > WQ_MEM_RECLAIM because of the loop device" then we're talking about
> > playing workqueue whack-a-mole across the entire kernel forever
> > more....
....
> And if WQs used by filesystem side do not want to use WQ_MEM_RECLAIM flag, the loop
> module would have to abuse __WQ_LEGACY flag in order to suppress this warning.

I'm not talking about whether filesysetms want to use WQ_MEM_RECLAIM
or not, I'm commenting on the implicit depedency that the loop
device creates that forces the use of WQ_MEM_RECLAIM in all
downstream workqueues. That's what I'm asking about here - how far
does this implicit, undocumented dependency actually reach and how
do we communicate to all developers so that they know about this in
the future when creating new workqueues that might end up under the
loop device?

That's the problem here - unless the developer explicitly considers
and/or remembers this loopback dependency when adding a new
workqueue to a filesystem (or even as far down as network stacks)
then this problem is going to keep happening and we'll just have to
keep driving WQ_MEM_RECLAIM deeper into the stack.

Tejun stated that just marking all workqueues as WQ_MEM_RECLAIM as
being problematic in some situations, and I'm concerned that
resolving implicit dependencies are going to end up in that
situation anyway.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com