Skip to contentSkip to conversation

loop: defer the queue limits clear to a workqueue

PATCH In review Tao Cui 3 participants 4 messages Sep 28 – Oct 5 Block layer

lore
Share & tools
lore

Tao Cui

author
#0 lore raw

PATCH v6 1/1 loop: defer the queue limits clear to a workqueue

From: Tao Cui <[email protected]>

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.

---
Changes since v5:

- Drop the rebind generation counters and instead cancel the work item from loop_change_fd() after the queue freeze and from __loop_clr_fd(), as suggested by Bart. This leaves no work item behind when the backing file changes, and the mutex now only protects clear_limits_mode.

Changes since v4:

- Rebase onto the current block tree as a single commit.

- Hold clear_limits_lock over the limits commit in the work item. The queue freeze is counted, not mutually exclusive, so loop_change_fd() could rebind between the generation check and the commit, and a stale clear could disable discard and write zeroes on the new backing file.

Changes since v3:

- Replace the three atomic variables (clear_limits_mode, rebind_gen, clear_limits_gen) with plain variables protected by a new clear_limits_lock mutex, as suggested by Bart. The mutex is taken after the queue freeze in the work item, which keeps the same freeze -> mutex ordering as loop_change_fd(), the only rebinding path that freezes the queue.

Changes since v2:

- Skip the clear when the device was rebound since the work item was scheduled: the modes used to be captured before the freeze, so a LOOP_CHANGE_FD completing in between could apply the old modes to the new backing file. The rebind generation is now checked with the queue frozen, which excludes loop_change_fd() because it assigns the new backing file under the same freeze, so a rebind cannot slip in between the check and the commit.

- Also bump the rebind generation from __loop_clr_fd(): unbinding does not go through loop_assign_backing_file(), so a work item scheduled before the last close could otherwise commit a stale clear to the queue limits of the unbound device.

Changes since v1:

- Reset clear_limits_mode when assigning a new backing file, so stale modes do not clear limits of the new file.

- Cancel the work item from loop_remove() before del_gendisk():
the queue can already be in RCU-delayed freeing when lo_free_disk() cancels it.

Tested on x86-64 (qemu, vfat-backed loop device): a 30s discard and reconfigure loop exercises the clear path 287 times, no torn sysfs reads, no difference against the unpatched kernel.

---
 drivers/block/loop.c | 72 ++++++++++++++++++++++++++++++++++++++------
 1 file changed, 63 insertions(+), 9 deletions(-)
drivers/block/loop.c +63 -9
index 758c20678bf6c..92f3ae7324751 100644
@@ -67,6 +67,9 @@ struct loop_device {
 	struct list_head        rootcg_cmd_list;
 	struct list_head        idle_worker_list;
 	struct rb_root          worker_tree;
+	struct work_struct      clear_limits_work;
+	struct mutex		clear_limits_lock;
+	unsigned int		clear_limits_mode;
 	struct timer_list       timer;
 	bool			sysfs_inited;
 
@@ -222,9 +225,25 @@ static void loop_set_size(struct loop_device *lo, loff_t size)
 		kobject_uevent(&disk_to_dev(lo->lo_disk)->kobj, KOBJ_CHANGE);
 }
 
-static void loop_clear_limits(struct loop_device *lo, int mode)
+static void loop_clear_limits_workfn(struct work_struct *work)
 {
+	struct loop_device *lo =
+		container_of(work, struct loop_device, clear_limits_work);
 	struct queue_limits lim = queue_limits_start_update(lo->lo_queue);
+	unsigned int memflags;
+	int mode = 0;
+
+	/*
+	 * A rebind cannot race with this work item: loop_change_fd()
+	 * and __loop_clr_fd() cancel it, loop_configure() only runs on
+	 * an unbound device, on which no work item can be pending, and
+	 * loop_assign_backing_file() resets the accumulated modes.
+	 */
+	memflags = blk_mq_freeze_queue(lo->lo_queue);
+	mutex_lock(&lo->clear_limits_lock);
+	mode = lo->clear_limits_mode;
+	lo->clear_limits_mode = 0;
+	mutex_unlock(&lo->clear_limits_lock);
 
 	if (mode & FALLOC_FL_ZERO_RANGE)
 		lim.max_write_zeroes_sectors = 0;
@@ -233,15 +252,16 @@ static void loop_clear_limits(struct loop_device *lo, int mode)
 		lim.max_hw_discard_sectors = 0;
 		lim.discard_granularity = 0;
 	}
-
-	/*
-	 * XXX: this updates the queue limits without freezing the queue, which
-	 * is against the locking protocol and dangerous.  But we can't just
-	 * freeze the queue as we're inside the ->queue_rq method here.  So this
-	 * should move out into a workqueue unless we get the file operations to
-	 * advertise if they support specific fallocate operations.
-	 */
 	queue_limits_commit_update(lo->lo_queue, &lim);
+	blk_mq_unfreeze_queue(lo->lo_queue, memflags);
+}
+
+static void loop_clear_limits(struct loop_device *lo, int mode)
+{
+	mutex_lock(&lo->clear_limits_lock);
+	lo->clear_limits_mode |= mode;
+	mutex_unlock(&lo->clear_limits_lock);
+	schedule_work(&lo->clear_limits_work);
 }
 
 static int lo_fallocate(struct loop_device *lo, struct request *rq, loff_t pos,
@@ -518,6 +538,14 @@ static int loop_validate_file(struct file *file, struct block_device *bdev)
 static void loop_assign_backing_file(struct loop_device *lo, struct file *file)
 {
 	lo->lo_backing_file = file;
+	/*
+	 * Discard any modes recorded against the old backing file.  The
+	 * paths that can race with a pending work item cancel it before
+	 * they get here.
+	 */
+	mutex_lock(&lo->clear_limits_lock);
+	lo->clear_limits_mode = 0;
+	mutex_unlock(&lo->clear_limits_lock);
 	lo->old_gfp_mask = mapping_gfp_mask(file->f_mapping);
 	mapping_set_gfp_mask(file->f_mapping,
 			lo->old_gfp_mask & ~(__GFP_IO | __GFP_FS));
@@ -602,6 +630,12 @@ static int loop_change_fd(struct loop_device *lo, struct block_device *bdev,
 	/* and ... switch */
 	disk_force_media_change(lo->lo_disk);
 	memflags = blk_mq_freeze_queue(lo->lo_queue);
+	/*
+	 * The freeze drained the in-flight requests, so any clear they
+	 * scheduled is pending or running now; cancelling here leaves
+	 * no clear behind for the new backing file.
+	 */
+	cancel_work_sync(&lo->clear_limits_work);
 	mapping_set_gfp_mask(old_file->f_mapping, lo->old_gfp_mask);
 	loop_assign_backing_file(lo, file);
 	loop_update_dio(lo);
@@ -1148,6 +1182,16 @@ static void __loop_clr_fd(struct loop_device *lo)
 	lo->lo_backing_file = NULL;
 	spin_unlock_irq(&lo->lo_lock);
 
+	/*
+	 * Invalidate any clear that was scheduled against the old backing
+	 * file.  Unbinding cannot race with in-flight I/O, so cancelling
+	 * here leaves no work item behind.
+	 */
+	cancel_work_sync(&lo->clear_limits_work);
+	mutex_lock(&lo->clear_limits_lock);
+	lo->clear_limits_mode = 0;
+	mutex_unlock(&lo->clear_limits_lock);
+
 	lo->lo_device = NULL;
 	lo->lo_offset = 0;
 	lo->lo_sizelimit = 0;
@@ -1783,7 +1827,9 @@ static void lo_free_disk(struct gendisk *disk)
 		destroy_workqueue(lo->workqueue);
 	loop_free_idle_workers(lo, true);
 	timer_shutdown_sync(&lo->timer);
+	cancel_work_sync(&lo->clear_limits_work);
 	mutex_destroy(&lo->lo_mutex);
+	mutex_destroy(&lo->clear_limits_lock);
 	kfree(lo);
 }
 
@@ -2102,6 +2148,8 @@ static int loop_add(int i)
 	spin_lock_init(&lo->lo_lock);
 	spin_lock_init(&lo->lo_work_lock);
 	INIT_WORK(&lo->rootcg_work, loop_rootcg_workfn);
+	INIT_WORK(&lo->clear_limits_work, loop_clear_limits_workfn);
+	mutex_init(&lo->clear_limits_lock);
 	INIT_LIST_HEAD(&lo->rootcg_cmd_list);
 	disk->major		= LOOP_MAJOR;
 	disk->first_minor	= i << part_shift;
@@ -2140,6 +2188,12 @@ static int loop_add(int i)
 
 static void loop_remove(struct loop_device *lo)
 {
+	/*
+	 * Cancel early: the queue may already be in RCU-delayed freeing
+	 * by the time lo_free_disk() cancels the work item.
+	 */
+	cancel_work_sync(&lo->clear_limits_work);
+
 	/* Make this loop device unreachable from pathname. */
 	del_gendisk(lo->lo_disk);
 	blk_mq_free_tag_set(&lo->tag_set);
Signature · 1 line
2.43.0
#1 lore raw

drivers/block/loop.c static void __loop_clr_fd(struct loop_device *lo) · line 1189

Quoted 9 lines · Tao Cui
drivers/block/loop.c +5 -0
@@ -1148,6 +1182,16 @@ static void __loop_clr_fd(struct loop_device *lo)
  	lo->lo_backing_file = NULL;
  	spin_unlock_irq(&lo->lo_lock);
 
+	/*
+	 * Invalidate any clear that was scheduled against the old backing
+	 * file.  Unbinding cannot race with in-flight I/O, so cancelling
+	 * here leaves no work item behind.
+	 */

This comment is wrong - asynchronous I/O can still be in progress here. See also
https://lore.kernel.org/linux-block/[email protected]/

Should this patch perhaps be rebased on top of Tetsuo's series?

drivers/block/loop.c static void lo_free_disk(struct gendisk *disk) · line 1834

Quoted 9 lines
drivers/block/loop.c +2 -0
@@ -1783,7 +1827,9 @@ static void lo_free_disk(struct gendisk *disk)
  		destroy_workqueue(lo->workqueue);
  	loop_free_idle_workers(lo, true);
  	timer_shutdown_sync(&lo->timer);
+	cancel_work_sync(&lo->clear_limits_work);
  	mutex_destroy(&lo->lo_mutex);
+	mutex_destroy(&lo->clear_limits_lock);
  	kfree(lo);
  }

Is the above new cancel_work_sync() call really necessary?

drivers/block/loop.c static int loop_add(int i) · line 2199

Quoted 13 lines
drivers/block/loop.c +6 -0
@@ -2140,6 +2188,12 @@ static int loop_add(int i)
 
  static void loop_remove(struct loop_device *lo)
  {
+	/*
+	 * Cancel early: the queue may already be in RCU-delayed freeing
+	 * by the time lo_free_disk() cancels the work item.
+	 */
+	cancel_work_sync(&lo->clear_limits_work);
+
  	/* Make this loop device unreachable from pathname. */
  	del_gendisk(lo->lo_disk);
  	blk_mq_free_tag_set(&lo->tag_set);

Is the above new cancel_work_sync() call necessary since there is already an identical call in __loop_clr_fd()?

Thanks,

Bart.

author
#2 lore raw

Hi Bart,

Quoted 11 lines · Bart Van Assche
Quoted 8 lines · Tao Cui
drivers/block/loop.c +0 -0
@@ -1148,6 +1182,16 @@ static void __loop_clr_fd(struct loop_device *lo)
       lo->lo_backing_file = NULL;
       spin_unlock_irq(&lo->lo_lock);

  +    /*
+     * Invalidate any clear that was scheduled against the old backing +     * file.  Unbinding cannot race with in-flight I/O, so cancelling +     * here leaves no work item behind.
+     */

This comment is wrong - asynchronous I/O can still be in progress here.

You are right, asynchronous I/O can still be in flight in __loop_clr_fd(). I'll fix the comment.

Quoted 5 lines

See also
https://lore.kernel.org/linux-block/[email protected]/

Should this patch perhaps be rebased on top of Tetsuo's series?

On rebasing on top of Tetsuo's series: since you recommend it, I can rebase this patch on top of it - the cancel inside __loop_clr_fd() just moves along with the new structure, and the I/O flush there makes that cancel airtight.

Quoted 12 lines

drivers/block/loop.c static void lo_free_disk(struct gendisk *disk) · line 1834

Quoted 9 lines
drivers/block/loop.c +2 -0
@@ -1783,7 +1827,9 @@ static void lo_free_disk(struct gendisk *disk)
           destroy_workqueue(lo->workqueue);
       loop_free_idle_workers(lo, true);
       timer_shutdown_sync(&lo->timer);
+    cancel_work_sync(&lo->clear_limits_work);
       mutex_destroy(&lo->lo_mutex);
+    mutex_destroy(&lo->clear_limits_lock);
       kfree(lo);
   }

Is the above new cancel_work_sync() call really necessary?

Quoted 16 lines

drivers/block/loop.c static int loop_add(int i) · line 2198

Quoted 12 lines
drivers/block/loop.c +6 -0
@@ -2140,6 +2188,12 @@ static int loop_add(int i)
     static void loop_remove(struct loop_device *lo)
   {
+    /*
+     * Cancel early: the queue may already be in RCU-delayed freeing
+     * by the time lo_free_disk() cancels the work item.
+     */
+    cancel_work_sync(&lo->clear_limits_work);
+
       /* Make this loop device unreachable from pathname. */
       del_gendisk(lo->lo_disk);
       blk_mq_free_tag_set(&lo->tag_set);

Is the above new cancel_work_sync() call necessary since there is already an identical call in __loop_clr_fd()?

On the cancel in loop_remove(): i think this one is needed because asynchronous I/O may still complete after __loop_clr_fd() has run and queue the work item. Since the queue becomes eligible for RCU-delayed freeing before lo_free_disk() is reached, cancel_work_sync() before del_gendisk() ensures no pending clear_limits_work remains against that queue.

I'll send v7 with the comment fixed and the redundant cancel removed once Tetsuo's series has landed.

Thanks,
Tao.

Quoted 3 lines

Thanks,

Bart.

#3 lore raw
In reply to Tao Cui
Quoted 20 lines · Tao Cui

From: Tao Cui <[email protected]>

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.

Quoted 2 lines

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