Re: [PATCH] loop: replace freezing queue with quiesce when changing loop specific setting

[Christoph Hellwig <hch@lst.de>]

On Fri, Apr 04, 2025 at 08:06:05PM +0800, Ming Lei wrote:
> On Fri, Apr 04, 2025 at 11:11:49AM +0200, Christoph Hellwig wrote:
> > On Thu, Apr 03, 2025 at 06:54:14PM +0800, Ming Lei wrote:
> > > freeze queue should be used for changing block layer generic setting, such
> > > as logical block size, PI, ..., and it is enough to quiesce queue for
> > > changing loop specific setting.
> > 
> > Why?  A queue should generally be frozen for any setting affecting the
> > I/O path.  Nothing about generic or internal.
> 
> For any driver specific setting, quiesce is enough, because these settings
> are only visible in driver IO code path, quiesce does provide the
> required protection exactly.

What are "internal settings" please?  If you change the loop backing
file outstanding I/O is relevant.  If you change NVMe ANA or retry
policies are relevant as they are checked in the I/O completion handler.

> > This also misses an explanation of what setting this protects and why
> > you think this is safe and the sound fix.
> 
> 1) it is typical queue quiesce use case

What is the typical queue quiesce use case?  Why is it "typical" and
why is it safe.

> 
> 2) loop specific setting is only visible in loop queue_rq() & workfn, and
> quiesce does provide the sync for queue_rq()

_What_ loop specific setting.

> 3) for driver, quiesce is always preferred over freeze, and freeze is
> easily mis-used by driver, you know we have bad driver uses for freeze.

I am actually much more worried about quiesce.  It is much less well
defined.