Re: [PATCH] loop: don't call vfs_flush() with queue frozen

[Ming Lei <ming.lei@redhat.com>]

On Tue, Jan 14, 2025 at 11:05:00PM -0800, Christoph Hellwig wrote:
> On Wed, Jan 15, 2025 at 10:37:08AM +0800, Ming Lei wrote:
> > Actually some FSs may call kmalloc(GFP_KERNEL) with i_rwsem grabbed,
> > which could call into real deadlock if IO on the loop disk is caused by
> > the kmalloc(GFP_KERNEL).
> 
> Well, loop can always deadlock when the lower fs is doing allocations,
> even without the freeze.  I'm actually kinda surprised loop doesn't
> force a context noio as we'd really need that.

Loop does call mapping_set_gfp_mask(~(__GFP_IO|__GFP_FS)).

> 
> > > > because we're talking about different file systems instances.  The only
> > > > exception would be file systems taking global locks in the I/O path,
> > > > but I sincerely hope no one does that.
> > >  
> > > Didn't you see the report on fs_reclaim and sysfs root lock?
> > > 
> > > https://lore.kernel.org/linux-block/197b07435a736825ab40dab8d91db031c7fce37e.camel@linux.intel.com/
> > 
> > There are more, such as mm->mmap_lock[1], hfs SB 'cat_tree' lock[2]...
> > 
> > 
> > [1] https://lore.kernel.org/linux-block/67863050.050a0220.216c54.006f.GAE@google.com/
> > [2] https://lore.kernel.org/linux-block/67582202.050a0220.a30f1.01cb.GAE@google.com/
> 
> And all of these are caused by not breaking the dependency loop..

Can you share how to break the dependency? Such as fs_reclaim &
mm->mmap_lock.


Thanks,
Ming