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

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

On Mon, Apr 07, 2025 at 08:48:06AM +0200, Christoph Hellwig wrote:
> 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.

internal setting means the driver internal setting, which is only visible
for driver.

Here this setting(lo_offset, backing file, dio, ...) won't be used in completion
handler, so it is fine to use quiesce here for updating these loop specific
setting.

> 
> > > 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.

typical quiesce provides sync with driver's ->queue_rq(), and it is typical
that these driver settings are only used in driver submission code path.

> 
> > 
> > 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.

Any setting is only visible in loop driver, such lo_offset, backing file,
dio, ...

> 
> > 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.

It is widely used, and please see document of blk_mq_quiesce_queue().


Thanks,
Ming