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 02:41:40 +0100
Message-ID: <20150802014139.GA17109@ZenIV.linux.org.uk>
References: <alpine.LSU.2.11.1507311022320.10162@eggly.anvils>
 <CA+55aFxGp3Hn-CeFE1NTYDr7vt3xjqe2mV1BbZ2tYHpCxenuAA@mail.gmail.com>
 <alpine.LSU.2.11.1507311207160.11122@eggly.anvils>
 <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>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Dominique Martinet <asmadeus@codewreck.org>,
	Hugh Dickins <hughd@google.com>,
	"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: Linus Torvalds <torvalds@linux-foundation.org>
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <CA+55aFymnDY+kYeNY9Xak9kFGbJr5AMVVPGA0RzENoTVSumLJw@mail.gmail.com>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: linux-fsdevel.vger.kernel.org

On Sat, Aug 01, 2015 at 05:57:44PM -0700, Linus Torvalds wrote:

> Because it's not just that "!d_can_lookup()" case that triggers it,
> you also have that pattern in the RCU error case for may_lookup(), and
> get_link().

It feels like it might make sense to handle that in caller, but...
that goes only for cases when we are *NOT* going to continue after
successful transition to non-lazy mode.  And these two are not of
that sort - we do want to continue rather than restart everything
from scratch.

BTW, unlazy_walk() has too many arguments, all for the sake of one caller
(everything except lookup_fast() calls it with (nd, NULL, 0) as arguments)
and it might make sense to split the damn thing in two.  I have that in
a pending pile since the last cycle, but back then you have asked to stop
piling them up and let it settle, so I'd postponed that one along with other
cleanups...