From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:53491 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932664AbeARQ2k (ORCPT ); Thu, 18 Jan 2018 11:28:40 -0500 Date: Thu, 18 Jan 2018 17:26:29 +0100 From: David Sterba To: Anand Jain Cc: "Misono, Tomohiro" , dsterba@suse.cz, linux-btrfs@vger.kernel.org Subject: Re: [PATCH v4 2/4] btrfs: cleanup btrfs_mount() using btrfs_mount_root() Message-ID: <20180118162629.GQ13726@twin.jikos.cz> Reply-To: dsterba@suse.cz References: <7dbb897c-1f1d-b54b-0cea-2a1c6c1d5027@jp.fujitsu.com> <28c4963f-9e87-ce42-7c6a-85d32cd71951@oracle.com> <20180115192615.GF13726@twin.jikos.cz> <2e0c866f-42e4-6a9c-a562-e3724062b0f9@oracle.com> <9babe0fa-6f10-64e5-349c-582ddcfc8f41@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <9babe0fa-6f10-64e5-349c-582ddcfc8f41@oracle.com> Sender: linux-btrfs-owner@vger.kernel.org List-ID: 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.