Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751024AbbEREVH (ORCPT ); Mon, 18 May 2015 00:21:07 -0400 Received: from mail-ie0-f181.google.com ([209.85.223.181]:35422 "EHLO mail-ie0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750720AbbEREU4 (ORCPT ); Mon, 18 May 2015 00:20:56 -0400 MIME-Version: 1.0 In-Reply-To: <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> <20150517105535.GU7232@ZenIV.linux.org.uk> <20150518091601.5c95322c@notabene.brown> <20150518034249.GW7232@ZenIV.linux.org.uk> Date: Sun, 17 May 2015 21:20:56 -0700 X-Google-Sender-Auth: iWnxxTW-xfrrX3qTqfUywjxMhOA Message-ID: Subject: Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks From: Linus Torvalds To: Al Viro Cc: NeilBrown , Andreas Dilger , Dave Chinner , Linux Kernel Mailing List , linux-fsdevel , Christoph Hellwig Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2448 Lines: 57 On Sun, May 17, 2015 at 8:42 PM, Al Viro wrote: > > "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 [..]) For revalidate, yes we kind of have them as dentries. I say kind of, because it may be that we're only revalidating a directory in the middle, and the rest of the path will be all new lookups, and we don't have that part as dentries at all. But nobody is going to care about "revalidate" for those. HOWEVER. We haven't actually walked/parsed the rest of the pathname yet at that point, and we generally probably shouldn't, since we don't know if the filesystem really is going to care. Why do extra work that may not be useful? So if we really do want to do it, and some filesystem cares enough, I think we actually should just pass it in as a string, and then have a helper function to say "ok, filesystem, if you want to revalidate the rest of the path, use this function to turn the hinting string into more dentries". Because I don't think it's worth doing up-front if it's not clear that the filesystem is going to care. For example, the /proc filesystem uses d_revalidate() to re-check the pid entries. That does *not* mean that it wants the rest of the dentries pre-parsed at all. So by all means give it a "const char *hint" for the rest, but it's going to just ignore it anyway, so don't wast parsing it as "these will be the following dentries we will ask you to revalidate". So I do think that "const char *hint" might be the right thing to pass down if we really care about this sufficiently. Both to revalidate and to lookup(). We currently have that "rest" in lookup_slow() as nd->last.name + hashlen_len(nd->last.hash_len) and we could just pass that down to lookup_dcache (which does revalidate) and lookup_real() (which does the actual ->lookup). But I guess we could just save off 'name' into a new field in nameidata in link_path_walk() after we've removed the slashes? I don't know if it matters. We can mask off the slashes again if/when people want to use the hint, after all. Linus -- 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/