From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH RESEND v4 6/8] vfs: Add get_vfsmount_sb() function to get vfsmount from a given sb. Date: Fri, 30 Jan 2015 06:15:52 +0000 Message-ID: <20150130061550.GJ29656@ZenIV.linux.org.uk> References: <1422498281-20493-1-git-send-email-quwenruo@cn.fujitsu.com> <1422498281-20493-7-git-send-email-quwenruo@cn.fujitsu.com> <54CAD5DC.2060603@huawei.com> <54CAE1E3.1040406@cn.fujitsu.com> <20150130021445.GH29656@ZenIV.linux.org.uk> <54CB0520.2070008@huawei.com> <20150130043714.GI29656@ZenIV.linux.org.uk> <54CB17F1.2070902@huawei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Qu Wenruo , linux-btrfs@vger.kernel.org, linux-fsdevel To: Miao Xie Return-path: Content-Disposition: inline In-Reply-To: <54CB17F1.2070902@huawei.com> Sender: linux-btrfs-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Jan 30, 2015 at 01:34:41PM +0800, Miao Xie wrote: > > First of all, ->s_umount is not a mutex; it's rwsem. So you mean > > down_read_trylock(). As for the transient failures - grep for down_write > > on it... E.g. have somebody call mount() from the same device. We call > > sget(), which finds existing superblock and calls grab_super(). Sure, > > that ->s_umount will be released shortly, but in the meanwhile your trylock > > will fail... > > I know it, so I suggested to return -EBUSY in the previous mail. > I think it is acceptable method, mount/umount operations are not so many > after all. Er... What for, when there's a trivial variant that doesn't suffer those spurious -EBUSY? Seriously, just move sysfs removals up to make sure that any possible fs shutdown won't progress past those during sysfs IO and use sb_want_write/sb_dont_write to make sure it'll stay r/w for the duration. What's the problem?