Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1751894AbbERDnF (ORCPT <rfc822;w@1wt.eu>);
	Sun, 17 May 2015 23:43:05 -0400
Received: from zeniv.linux.org.uk ([195.92.253.2]:40787 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751375AbbERDmy (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 17 May 2015 23:42:54 -0400
Date: Mon, 18 May 2015 04:42:49 +0100
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: NeilBrown <neilb@suse.de>, Andreas Dilger <adilger@dilger.ca>,
        Dave Chinner <david@fromorbit.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        Christoph Hellwig <hch@infradead.org>
Subject: Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU
 symlinks
Message-ID: <20150518034249.GW7232@ZenIV.linux.org.uk>
References: <20150516144527.20b89194@notabene.brown>
 <20150516054626.GS7232@ZenIV.linux.org.uk>
 <20150516141811.GT7232@ZenIV.linux.org.uk>
 <20150517131203.7342afc8@notabene.brown>
 <CA+55aFwsBkGOrYz_EhXhUB9cbjciV2nLxgd4NoHTjoTnjjGTLw@mail.gmail.com>
 <CA+55aFy_6OqijwYjKbSXk209Crgg34F+2sWPwZeQWbj3UopLeg@mail.gmail.com>
 <20150517105535.GU7232@ZenIV.linux.org.uk>
 <CA+55aFzJqBwPstg6x=r0wN5zdpwuUsEeHRG4A1SnHsRfLJ43cQ@mail.gmail.com>
 <20150518091601.5c95322c@notabene.brown>
 <CA+55aFzzTPBhg__P597uh70fezshqS5JscGwkw21anRg7_bwwA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+55aFzzTPBhg__P597uh70fezshqS5JscGwkw21anRg7_bwwA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2940
Lines: 54

On Sun, May 17, 2015 at 07:56:26PM -0700, Linus Torvalds wrote:
 
> > So for Al's example of revalidating multiple components at once, once the VFS
> > gets to a point in the path where  d_revalidate says "I need more time",
> > the VFS just passes the rest of the path to the filesystem.
> 
> That's bullshit,. for a very simple and basic reason: "the rest of the
> path" is not necessarily at all for your filesystem!
> 
> Really. There might be mount-points, there might be symlinks, there
> might be tons of stuff like that.

"Rest of the path" makes no sense, obviously.  "More of the path" (and _not_
as a string, TYVM - we have those components in ->d_name.name of dentries we
want revalidated, complete with hashes, so WTF redo that?) is fine, though,
because the caller knows exactly where the mountpoints are, so we know how far
we can go.

> Now, this is why I said we can do a "hint" style thing. Part of that
> "hint" issue is very very much that it has no semantic meaning. You
> can't screw it up, because if it turns out that the path component
> we're looking up is a symlink and we actually end up in some other
> filesystem, if you end up looking up the hint part, it just would
> never actually get used.

For revalidate "this used to be a symlink, now it's not" or vice versa
means simply "it's gone stale".  Which is fine - again, the caller knows
where in that chain the symlinks are (and they obviously terminate the
chain to be revalidated).

Anyway, it's a side issue; we _can_ use the capability to do multi-component
lookups and with link_path_walk()-related logics getting untangled, we might
be able to do just that without messing the code up.  It's very clearly not
a 4.2 fodder, though, and I'm not sure how high priority it is for 4.3,
simply because making the exclusion between lookups weaker seems to be
of more general interest.  And those two will definitely be stepping on the
same area, so it probably makes more sense to sort the parallel lookups out
first.  _IF_ we manage to get that by 4.3-rc<early>, sure, continuation into
multicomponent lookups would start looking as 4.3 material.  Hell knows -
stranger things have happened...

What we really need is a coherent documentation on the whole pathname-related
machinery; I've some preliminary bits and pieces written, but it'll take
more work.  Hopefully I'll have something postable in a week or less...

Right now I can think of 4 or 5 people familiar with the area, myself
included.  And we need more - it shouldn't be a fucking black magic, since
fs folks really ought to understand what's going on there.  The thing is,
under the assorted layers of cruft it's simpler than e.g. VMA handling...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/