loop: defer the queue limits clear to a workqueue
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
@@ -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
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.
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.
Quoted 20 lines · Tao Cui
From: Tao Cui <[email protected]>
loop_clear_limits()callsqueue_limits_commit_update()directly from the loop workqueue that processes the request. That does a non-atomic struct assignment toq->limitswithout freezing the queue, which races with lockless readers ofq->limitson other CPUs - bio splitting readsmax_hw_sectors, the discard path readsmax_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, andloop_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
Suggested-by Bart Van Assche <[email protected]>Signed-off-by Tao Cui <[email protected]>
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