From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [git pull] vfs.git spurious ENOTDIR fix
Date: Sun, 2 Aug 2015 05:39:47 +0100
Message-ID: <20150802043947.GB17109@ZenIV.linux.org.uk>
References: <20150731205036.GA3752@nautica>
 <CA+55aFz9jj_wAjXNoFbKFbV3M1Ki2KhHuoMwQGPi0wiQjMXdsw@mail.gmail.com>
 <20150801072603.GV17109@ZenIV.linux.org.uk>
 <CA+55aFx7OY8X=s=oc5HUeWeA-5vWqkH+gcOV80xC=xXv9Q3AnQ@mail.gmail.com>
 <20150802001402.GY17109@ZenIV.linux.org.uk>
 <20150802002318.GZ17109@ZenIV.linux.org.uk>
 <CA+55aFymnDY+kYeNY9Xak9kFGbJr5AMVVPGA0RzENoTVSumLJw@mail.gmail.com>
 <20150802014139.GA17109@ZenIV.linux.org.uk>
 <CA+55aFwrctpGzdFBsqwz97NOUBbWncdik-axas1vcNeyUXFHrA@mail.gmail.com>
 <alpine.LSU.2.11.1508012045250.17084@eggly.anvils>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Dominique Martinet <asmadeus@codewreck.org>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Dominique Martinet <dominique.martinet@cea.fr>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	David Howells <dhowells@redhat.com>
To: Hugh Dickins <hughd@google.com>
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <alpine.LSU.2.11.1508012045250.17084@eggly.anvils>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Sat, Aug 01, 2015 at 09:06:55PM -0700, Hugh Dickins wrote:

> (I don't actually understand why the clearing of DCACHE_ENTRY_TYPE in
> dentry_iput() is not of continuing concern; but don't worry, there's
> plenty I don't understand - so long as you're both satisfied that
> it's not a concern, no need to persuade me.)

Because before we even get to dentry_iput(), we evict the fucker from hash.
And that will do dentry_rcuwalk_invalidate(dentry), which will bump ->d_seq
*AFTER* having it unhashed.  Now look at __d_lookup_rcu() - there we fetch
->d_seq, then verify that it's still hashed.

So having hit dentry_iput() means that everyone who'd found it via RCU
lookup will be guaranteed a ->d_seq mismatch.  The same goes for things
like d_drop() and d_instantiate().  Look for dentry_rcuwalk_invalidate()
callers in there...

Clearing DCACHE_ENTRY_TYPE there is fine - dentry *is* made negative there,
after all.  What we want is to have ->d_inode stable at least as long as
->d_seq remains so.