On Wed, Jan 15, 2025 at 04:21:40PM +0800, Ming Lei wrote: > 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)). But that only helps with page cache allocations, not other allocations don't in the I/O path, of which there are plenty in modern file systems. > > 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. fs_reclaim should not be broken. It's a fake lockdep key annotation the reclaim path. Everything under it needs to be NOFS, or in case of loop NOIO (see above). I think mmap_lock is just an indirect chain here, but I need to take a closer look. A little busty this week and only sporadically online, sorry.
