Re: [PATCH v6] loop: defer the queue limits clear to a workqueue

[Shin'ichiro Kawasaki]

On Sep 28, 2026 / 17:35, Tao Cui wrote:
> From: Tao Cui <cuitao@xxxxxxxxxx>
> 
> loop_clear_limits() calls queue_limits_commit_update() directly from
> the loop workqueue that processes the request.  That does a
> non-atomic struct assignment to q->limits without freezing the queue,
> which races with lockless readers of q->limits on other CPUs - bio
> splitting reads max_hw_sectors, the discard path reads
> max_hw_discard_sectors - and can let them observe torn values.  The
> trigger is a discard or write-zeroes request on a loop device whose
> backing file does not support the corresponding fallocate operation.
> 
> The code already has an XXX comment saying this should move to a
> workqueue.  Do that: schedule a work item on the system workqueue, where
> it is safe to freeze the queue around the limits update.  The pending
> modes live under a new mutex, lo->clear_limits_lock.
> loop_change_fd() and __loop_clr_fd() cancel the work item before
> changing or dropping the backing file, and loop_assign_backing_file()
> resets the modes, so a stale clear cannot hit the new backing file.
> The work item is also cancelled before the device is freed.
> 
> Suggested-by: Bart Van Assche <bvanassche@xxxxxxx>
> Signed-off-by: Tao Cui <cuitao@xxxxxxxxxx>

FYI, blktests CI observed the failure of loop/011 test case with this patch:

  loop/011 (Make sure unsupported backing file fallocate does not fill dmesg with errors) [failed]
      runtime    ...  0.737s
      --- tests/loop/011.out	2026-10-05 09:59:42.755411625 +0000
      +++ /home/runner/blktests/results/nodev/loop/011.out.bad	2026-10-05 10:42:15.607566132 +0000
      @@ -1,3 +1,3 @@
       Running loop/011
      -Found 1 error(s) in dmesg
      +Found 2 error(s) in dmesg
       Test complete