On 3/8/24 21:40, Christoph Hellwig wrote:
On Fri, Mar 08, 2024 at 09:34:03PM +0530, Anand Jain wrote:
bdev_open_by_path. bdev_open_by_path bdev_open_by_path calls
lookup_bdev to translate the path to a dev_t and then calls
bdev_open_by_dev on the dev_t, which stored the passes in dev_t in
bdev->bd_dev. I see absolutely no way how this check could ever
trigger.
Prior to this patch, the device->devt value of the device could become
stale, as it might not have been updated since the last scan of the
device. During this interval, the device could have undergone changes
to its devt.
How can it become stale here? btrfs_open_one_device exits early
if device->bdev is set, so you set up a new device->bdev and
stash the just opened bdev there. The dev_t of an existing
struct block_device never changes, so it must match the one
in the btrfs_device that was just initialized from it.
It's a bit complex, as Boris discovered and has provided a testcase
for here:
https://lore.kernel.org/fstests/f40e347d5a4b4b28201b1a088d38a3c75dd10ebd.1709251328.git.boris@xxxxxx/
In essence:
- Create two devices, d1 and d2.
- Both devices will be scanned into the kernel by Mfks.
- Use an external method to alter the devt of the d2 device.
- Mount using d1.
- You end up with a 2 devices Btrfs with an incorrect device->devt.
- Delete d1.
- Now you have a single-device Btrfs on d2 with a stale device->devt.
Thanks, Anand
