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.170...
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