Skip to content

Commit a4d85bf

Browse files
author
Ming Lei
committed
loop: fix queue freeze vs limits lock order
JIRA: https://issues.redhat.com/browse/RHEL-71345 Upstream Status: for-6.4/block commit b03732a Author: Christoph Hellwig <hch@lst.de> Date: Fri Jan 10 06:47:19 2025 +0100 loop: fix queue freeze vs limits lock order Match the locking order used by the core block code by only freezing the queue after taking the limits lock using the queue_limits_commit_update_frozen helper and document the callers that do not freeze the queue at all. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Nilay Shroff <nilay@linux.ibm.com> Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Link: https://lore.kernel.org/r/20250110054726.1499538-12-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Ming Lei <ming.lei@redhat.com>
1 parent 98e4fa2 commit a4d85bf

File tree

1 file changed

+16
-2
lines changed

1 file changed

+16
-2
lines changed

drivers/block/loop.c

Lines changed: 16 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -313,6 +313,13 @@ static void loop_clear_limits(struct loop_device *lo, int mode)
313313
lim.discard_granularity = 0;
314314
}
315315

316+
/*
317+
* XXX: this updates the queue limits without freezing the queue, which
318+
* is against the locking protocol and dangerous. But we can't just
319+
* freeze the queue as we're inside the ->queue_rq method here. So this
320+
* should move out into a workqueue unless we get the file operations to
321+
* advertise if they support specific fallocate operations.
322+
*/
316323
queue_limits_commit_update(lo->lo_queue, &lim);
317324
}
318325

@@ -1093,6 +1100,7 @@ static int loop_configure(struct loop_device *lo, blk_mode_t mode,
10931100

10941101
lim = queue_limits_start_update(lo->lo_queue);
10951102
loop_update_limits(lo, &lim, config->block_size);
1103+
/* No need to freeze the queue as the device isn't bound yet. */
10961104
error = queue_limits_commit_update(lo->lo_queue, &lim);
10971105
if (error)
10981106
goto out_unlock;
@@ -1153,7 +1161,12 @@ static void __loop_clr_fd(struct loop_device *lo)
11531161
lo->lo_sizelimit = 0;
11541162
memset(lo->lo_file_name, 0, LO_NAME_SIZE);
11551163

1156-
/* reset the block size to the default */
1164+
/*
1165+
* Reset the block size to the default.
1166+
*
1167+
* No queue freezing needed because this is called from the final
1168+
* ->release call only, so there can't be any outstanding I/O.
1169+
*/
11571170
lim = queue_limits_start_update(lo->lo_queue);
11581171
lim.logical_block_size = SECTOR_SIZE;
11591172
lim.physical_block_size = SECTOR_SIZE;
@@ -1473,9 +1486,10 @@ static int loop_set_block_size(struct loop_device *lo, unsigned long arg)
14731486
sync_blockdev(lo->lo_device);
14741487
invalidate_bdev(lo->lo_device);
14751488

1476-
blk_mq_freeze_queue(lo->lo_queue);
14771489
lim = queue_limits_start_update(lo->lo_queue);
14781490
loop_update_limits(lo, &lim, arg);
1491+
1492+
blk_mq_freeze_queue(lo->lo_queue);
14791493
err = queue_limits_commit_update(lo->lo_queue, &lim);
14801494
loop_update_dio(lo);
14811495
blk_mq_unfreeze_queue(lo->lo_queue);

0 commit comments

Comments
 (0)