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

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

On Mon, Jan 13, 2025 at 01:18:00AM -0800, Christoph Hellwig wrote:
> On Mon, Jan 13, 2025 at 04:22:51PM +0800, Ming Lei wrote:
> > On Sun, Jan 12, 2025 at 09:49:39PM -0800, Christoph Hellwig wrote:
> > > On Mon, Jan 13, 2025 at 10:24:26AM +0800, Ming Lei wrote:
> > > > If vfs_flush() is called with queue frozen, the queue freeze lock may be
> > > > connected with FS internal lock
> > > 
> > > What "FS internal lock" ?
> > 
> > Please see the report:
> > 
> > https://lore.kernel.org/linux-block/359BC288-B0B1-4815-9F01-3A349B12E816@m.fudan.edu.cn/T/#u
> 
> Please state the locks.  Nothing fs internal here, that report is
> about i_rwsem.  And a false positive because it is about ordering
> of i_rwsem on the upper file system sitting on the loop device vs the
> one on the lower file systems sitting below the block device.  These
> obviously can't deadlock, we just need to tell lockdep about that fact.

How can you guarantee that some code won't submit IO by grabbing the
i_rwsem?

As I explained, it is fine to move out vfs_fsync() out of freeze queue.

Actually any lock which depends on freeze queue needs to take a careful
look, because freeze queue connects too many global/sub-system locks.

Thanks,
Ming