Re: [PATCH 1/2] loop: drop stale partitions on LOOP_CHANGE_FD

On Aug 06, 2026 / 12:36, Daan De Meyer via B4 Relay wrote:
> From: Daan De Meyer <[email protected]>
> 
> Commit 267ec4d7223a ("loop: fix partition scan race between udev and
> loop_reread_partitions()") stopped disk_force_media_change() from
> setting GD_NEED_PART_SCAN. That bit did more than request a rescan:
> bdev_disk_changed() drops every partition before it consults
> disk_has_partscan(), so the lazy scan on the next open was also what
> removed partitions from a loop device without LO_FLAGS_PARTSCAN.
> 
> Such devices are not unusual. bdev_add_partition() only rejects
> GENHD_FL_NO_PART disks, so BLKPG_ADD_PARTITION works while
> GD_SUPPRESS_PART_SCAN is set, and parted, libfdisk and systemd all fall
> back to BLKPG when BLKRRPART fails with -EINVAL, which is what a loop
> device without LO_FLAGS_PARTSCAN returns.
> 
> loop_change_fd() only rescans when LO_FLAGS_PARTSCAN is set, so those
> partitions now survive the backing file swap and keep describing the old
> file. The new backing file must have the same size, but its partition
> table can be completely different, leaving the partition devices mapping
> the wrong ranges.
> 
> Call loop_reread_partitions() unconditionally. Without LO_FLAGS_PARTSCAN,
> blk_add_partitions() returns early, so this drops the stale partitions
> without scanning the new backing file.

Daan also posted a new, blktests test case that recreates the problem described
[*]. I confirmed that the test case failed with v7.2-rc7 kernel, and this patch
avoids the failure.

Tested-by: Shin'ichiro Kawasaki <[email protected]>

[*] https://github.com/linux-blktests/blktests/pull/259