On Mon, Jun 04, 2018 at 11:00:30PM +0800, Anand Jain wrote: > In an instrumented testing it is possible that the mount and > a newer mkfs.btrfs thread on the same device can race and if the new > mkfs.btrfs wins it will free the older fs_devices, then the mount thread > will lead to oops. > > Thread1 Thread2 > ------- ------- > mkfs.btrfs -fq /dev/sdb > mount /dev/sdb /btrfs > |_btrfs_mount_root() > |_btrfs_scan_one_device(... &fs_devices) > > mkfs.btrfs -fq /dev/sdb > |_btrfs_contol_ioctl() > |_btrfs_scan_one_device(... > &fs_devices) > |_:: > > |_btrfs_free_stale_devices() > > |_btrfs_open_devices(fs_devices ..) <-- stale fs_devices. > > Fix this with a mutually exclusive flag BTRFS_VOL_FLAG_EXCL_OPS.
I'm not sure this is the right way to fix it, adding another bit to the uuid_mutex and device_list_mutex combo. To fix the race between mount and mkfs we can add a bit of logic to the device scanning so that mount calling scan will track the purpose and mkfs scan will not be allowed to free that device. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
