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: Mon, 18 Jul 2011 19:20:30 +0100 Message-ID: <20110718182030.GF11013@ZenIV.linux.org.uk> References: <20110717231610.GR11013@ZenIV.linux.org.uk> <20110718002524.GU11013@ZenIV.linux.org.uk> <20110718020818.GW11013@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 To: Linus Torvalds Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, Jul 18, 2011 at 11:11:40AM -0700, Linus Torvalds wrote: > Also, looking at that whole mount-point traversal sequence, it looks > like __follow_mount_rcu() will happily totally ignore the old sequence > number when it replaces it with the mount-point sequence number. So it > looks to me that we have a case where we miss the sequence number > check that can happen with a positive dentry too! > > No? > > So I think that whenever we change "nd->seq", we should always heck > the previous sequence number first (the way do_lookup() itself does > for the *normal* traversal case). Otherwise we will have traversed the > mount-point without ever having checked the previous sequence number. > > Something like the (untested) attached patch. > > Comments? This mount-point case is independent of the negative dentry > issue, and probably never really an issue in practice, but... ->mnt_mountpoint and ->mnt_root are both pinned (and protected by vfsmount_lock, while we are at it). If it manages to get stale, we have worse problems...