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@xxxxxxxxxxxxx
