From mboxrd@z Thu Jan 1 00:00:00 1970 From: Qu Wenruo 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 13:30:47 +0800 Message-ID: <54CB1707.2030202@cn.fujitsu.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: , linux-fsdevel To: Miao Xie , Al Viro Return-path: Received: from cn.fujitsu.com ([59.151.112.132]:49607 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750708AbbA3Fax convert rfc822-to-8bit (ORCPT ); Fri, 30 Jan 2015 00:30:53 -0500 In-Reply-To: <54CB0520.2070008@huawei.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: -------- Original Message -------- Subject: Re: [PATCH RESEND v4 6/8] vfs: Add get_vfsmount_sb() function=20 to get vfsmount from a given sb. =46rom: Miao Xie To: Al Viro , Qu Wenruo Date: 2015=E5=B9=B401=E6=9C=8830=E6=97=A5 12:14 > On Fri, 30 Jan 2015 02:14:45 +0000, Al Viro wrote: >> On Fri, Jan 30, 2015 at 09:44:03AM +0800, Qu Wenruo wrote: >> >>> This shouldn't happen. If someone is ro, the whole fs should be ro,= right? >> Wrong. Individual vfsmounts over an r/w superblock might very well = be r/o. >> As for that trylock... What for? It invites transient failures for= no >> good reason. Removal of sysfs entry will block while write(2) to th= at sucker >> is in progress, so btrfs shutdown will block at that point in ctree_= close(). >> It won't go away under you. > could you explain the race condition? I think the deadlock won't happ= en, during > the btrfs shutdown, we hold s_umount, the write operation will fail t= o lock it, > and quit quickly, and then umount will continue. > > I think sb_want_write() is similar to trylock(s_umount), the differen= ce is that > sb_want_write() is more complex. How? sb_want_write() should be much like mnt_want_write(), except no need to= =20 increase vfsmout ref count things and no need to check per mount ro/rw things. Thanks, Qu > >> Now, you might want to move those sysfs entry removals to the very b= eginning >> of btrfs_kill_super(), but that's a different story - you need only = to make >> sure that they are removed not later than the destruction of the dat= a >> structures they need (IOW, the current location might very well be O= K - I >> hadn't checked the details). > Yes, we need move those sysfs entry removals, but needn't move to the= very > beginning of btrfs_kill_super(), just at the beginning of close_ctree= (); > > The current location is not right, it will introduce the use-after-fr= ee > problem. because we remove the sysfs entry after we release > transaction_kthread, use-after-free problem might happen in this case > Task1 Task2 > change Label by sysfs > close_ctree > kthread_stop(transaction_kthread); > change label > wake_up(transaction_kthread) > > > Thanks > Miao > >> As for "it won't go r/o under us" - sb_want_write() will do that jus= t fine. >> . >> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html