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

[Anand Jain <anand.jain@oracle.com>]

On 01/17/2018 04:30 PM, Misono, Tomohiro 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.
> 
> BTW, I noticed "btrfs device scan/ready" fails for mounted filesystem
> because of this reason. 
  Oh yes I can reproduce too using [1], very consistently.

 > I will send a patch to fix this.
> (Though I believe this is not the cause of the problem you mentioned.)



> Thanks,
> Tomohiro
> 
>>>
>>> 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.

David,

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


>> Quite strange, there isn't any
>>    concurrency (mount and scan) in this test case.

  Now this strangeness is explained.

>>    [1]
>>      git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git for-next
>>
>>    Ran xfstests, got stuck at btrfs/011 failures, (and will wait for
>>    Liubo's v2 patch).


>> OR is there any other test case you were referring
>>    to as random test failures ?

  Anything on this ? I can take a look.

Thanks, Anand

>> Thanks, Anand