From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH] vfs: fix race in rcu lookup of pruned dentry Date: Wed, 20 Jul 2011 00:52:16 +0100 Message-ID: <20110719235215.GS11013@ZenIV.linux.org.uk> References: <20110718020818.GW11013@ZenIV.linux.org.uk> <20110718194703.GI11013@ZenIV.linux.org.uk> <20110719234550.GR11013@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Hugh Dickins , Andrew Morton , Nick Piggin , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, neilb@suse.de To: Linus Torvalds Return-path: Content-Disposition: inline In-Reply-To: <20110719234550.GR11013@ZenIV.linux.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, Jul 20, 2011 at 12:45:51AM +0100, Al Viro wrote: > You know what... I doubt that you want to mess with ->d_seq checks here. > It's definitely not Hugh's bug (unless he has bindings somewhere odd) and > both ->mnt_mountpoint and ->mnt_root are pinned (and we are holding > vfsmount_lock anyway). *inode assignment too early is a real bug, indeed, > and we want to assign nd->seq if we cross mountpoint as both versions do, > but check just before that is, in the best case, BUG_ON() fodder. We'd > just found a vfsmount with ->mnt_mountpoint equal to path->dentry; it *can't* > be stale, or we have a really nasty problem anyway. Kudos to neilb for spotting the pointless check, BTW; and no, his theory that it might be needed since we could race with umount() is wrong - due to vfsmount_lock being held.