summaryrefslogtreecommitdiff
path: root/rust/kernel/alloc
diff options
context:
space:
mode:
authorDaan De Meyer <daan@amutable.com>2026-07-15 21:39:57 +0200
committerJens Axboe <axboe@kernel.dk>2026-07-15 16:31:14 -0600
commitc4f4c0fc551cbcdccbbbc2d874d7d6440c7b4983 (patch)
tree86802f749d75c3d07492996796e4cd3289ced323 /rust/kernel/alloc
parent691b052139c94ee6640ac39e0b764dd3867897c0 (diff)
loop: remove manually added partitions on detach
Commit 267ec4d7223a ("loop: fix partition scan race between udev and loop_reread_partitions()") stopped disk_force_media_change() from setting GD_NEED_PART_SCAN because loop devices with LO_FLAGS_PARTSCAN rescan partitions explicitly. However, partitions can also be added manually with BLKPG while LO_FLAGS_PARTSCAN is clear. When such a loop device is detached, __loop_clr_fd() skips bdev_disk_changed(). Without GD_NEED_PART_SCAN, reopening the unbound device no longer performs the previous lazy cleanup, leaving dead partition devices behind. A subsequent LOOP_CONFIGURE can then fail its partition scan with -EBUSY, as seen in blktests loop/009 after loop/008. Call bdev_disk_changed() unconditionally during __loop_clr_fd(). The disk capacity is already zero and the release path holds open_mutex, so this drops all partitions without rescanning the detached backing file. The new blktests loop/013 case covers this sequence by adding a partition with BLKPG without LO_FLAGS_PARTSCAN, detaching the loop device, and checking that the partition is gone when the device is reopened. Fixes: 267ec4d7223a ("loop: fix partition scan race between udev and loop_reread_partitions()") Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202607150754.b660f5b9-lkp@intel.com Signed-off-by: Daan De Meyer <daan@amutable.com> Link: https://patch.msgid.link/20260715-b4-loop-partition-cleanup-v1-1-b9f59910cd1e@amutable.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
Diffstat (limited to 'rust/kernel/alloc')
0 files changed, 0 insertions, 0 deletions