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