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@xxxxxxxxxxxxxx/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
