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.... During an attempt to fix lockdep warning caused by calling destroy_workqueue() when loop device's autoclear operation is triggered with disk->open_mutex held, Christoph has proposed a patch which avoids calling destroy_workqueue() by using a global WQ. But like demonstrated at https://lkml.kernel.org/r/22b51922-30c6-e4ed-ace9-5620f877682c@xxxxxxxxxxxxxxxxxxx , I confirmed that the loop module needs to reserve one "struct task_struct" on each loop device's WQ. And creating per loop device WQ with WQ_MEM_RECLAIM flag is the only available method for reserving "struct task_struct" on each loop device's WQ. That is, WQ_MEM_RECLAIM flag is required for not only surviving memory pressure situation but also surviving max active limitation. But like demonstrated at https://lkml.kernel.org/r/61f41e56-3650-f0fc-9ef5-7e19fe84e6b7@xxxxxxxxxxxxxxxxxxx , creating per loop device WQ with WQ_MEM_RECLAIM flag without __WQ_LEGACY flag will hit this "workqueue: WQ_MEM_RECLAIM %s:%ps is flushing !WQ_MEM_RECLAIM %s:%ps" warning. 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.
