Re: [PATCH v4 2/4] btrfs: cleanup btrfs_mount() using btrfs_mount_root()

[David Sterba <dsterba@suse.cz>]

On Thu, Jan 18, 2018 at 12:48:37PM +0800, Anand Jain wrote:
> > On 2018/01/16 20:45, Anand Jain wrote:
> >> On 01/16/2018 03:26 AM, David Sterba wrote:
> >>> On Fri, Jan 12, 2018 at 06:14:40PM +0800, Anand Jain wrote:
> >>>>
> >>>> Misono,
> >>>>
> >>>>     This change is causing subsequent (subvol) mount to fail when device
> >>>>     option is specified. The simplest eg for failure is ..
> >>>>       mkfs.btrfs -qf /dev/sdc /dev/sdb
> >>>>       mount -o device=/dev/sdb /dev/sdc /btrfs
> >>>>       mount -o device=/dev/sdb /dev/sdc /btrfs1
> >>>>          mount: /dev/sdc is already mounted or /btrfs1 busy
> >>>>
> >>>>      Looks like
> >>>>        blkdev_get_by_path() <-- is failing.
> >>>>        btrfs_scan_one_device()
> >>>>        btrfs_parse_early_options()
> >>>>        btrfs_mount()
> >>>>
> >>>>     Which is due to different holders (viz. btrfs_root_fs_type and
> >>>>     btrfs_fs_type) one is used for vfs_mount and other for scan,
> >>>>     so they form different holders and can't let EXCL open which
> >>>>     is needed for both scan and open.
> >>> This looks close to what I see in the random test failures. I've
> >>> reverted your patch "btrfs: optimize move uuid_mutex closer to the
> >>> critical section" as I bisected to it. The uuid mutex around
> >>> blkdev_get_path probably protected the concurrent mount and scan so they
> >>> did not ask for EXCL at the same time.
> >>>
> >>> Reverting (or removing the patch from the current misc-next) queue is
> >>> simpler for me ATM as I want to get to a stable base now, we can add it
> >>> later if we understand the issue with the mount/scan.
> >>    Right. I don't see above test case failing on your branch [1] which
> >>    does not have the uuid_mutex patch.
> 
>   Sorry I was wrong. Looks like I have booted wrong kernel to test.
>   So I see the same problem even you have reverted the patch:
>     'btrfs: optimize move uuid_mutex closer to the critical section'
>   in [1].

Yeah, the revert was result of an unreliable bisect, though I tried to
run the reproducers repeatedly. I'm going to consider the patch again.