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@xxxxxxxxxxxxxxx/ > > > > 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@xxxxxxxxxx/ > > [2] https://lore.kernel.org/linux-block/67582202.050a0220.a30f1.01cb.GAE@xxxxxxxxxx/ > > 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
