Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751771AbbEQDMV (ORCPT ); Sat, 16 May 2015 23:12:21 -0400 Received: from cantor2.suse.de ([195.135.220.15]:43470 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750849AbbEQDMN (ORCPT ); Sat, 16 May 2015 23:12:13 -0400 Date: Sun, 17 May 2015 13:12:03 +1000 From: NeilBrown To: Al Viro Cc: Linus Torvalds , Andreas Dilger , Dave Chinner , Linux Kernel Mailing List , linux-fsdevel , Christoph Hellwig Subject: Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks Message-ID: <20150517131203.7342afc8@notabene.brown> In-Reply-To: <20150516141811.GT7232@ZenIV.linux.org.uk> References: <20150514033040.GF7232@ZenIV.linux.org.uk> <20150514112304.GT15721@dastard> <20150516093022.51e1464e@notabene.brown> <20150516112503.2f970573@notabene.brown> <20150516014718.GO7232@ZenIV.linux.org.uk> <20150516144527.20b89194@notabene.brown> <20150516054626.GS7232@ZenIV.linux.org.uk> <20150516141811.GT7232@ZenIV.linux.org.uk> X-Mailer: Claws Mail 3.10.1-162-g4d0ed6 (GTK+ 2.24.25; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/doXnCWrckpgS=Ndw1Ez=JIf"; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4085 Lines: 90 --Sig_/doXnCWrckpgS=Ndw1Ez=JIf Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 16 May 2015 15:18:11 +0100 Al Viro wrote: > On Sat, May 16, 2015 at 06:46:26AM +0100, Al Viro wrote: >=20 > > Dealing with multi-component lookups isn't impossible and might be a go= od > > idea, but only if all intermediates are populated. What information do= es > > NFSv4 multi-component lookup give you? 9p one gives an array of FIDs, > > one per component, and that is best used as multi-component revalidate > > on hot dcache... >=20 > Having reread the RFC... What's the problem with intermediates? > Just put GETFH and GETATTR between the LOOKUP for each component in > the same compound and be done with that - you've got yourself everything > you might possibly need for populating them. Confused... The problem isn't getting intermediates. The problem is that not having intermediates confuses the dcache. When the dcache is just providing a caching service, and not providing a consistency service, then it shouldn't let itself get confused. >=20 > BTW, I would still very much prefer to allocate a chain of > dentries in fs/namei.c (yes, marking them "in-lookup"), then gave an > array of pointers (or beginning and end of the chain, but that can > be more delicate due to dentry tree topology changes from e.g. > d_materialize_unique(), aka d_splice_alias() these days). With > the requirement being "populate them in root-to-leaves order, do nothing > for ones that had in-lookup flag already cleared". >=20 > Another fun possibility (but that would take somewhat more > restructuring in fs/namei.c) would be to have (on hot cache) a path > traced for several components, seeing that they are all on the same > fs and delaying revalidation for a while. With bulk revalidate covering > all the chain when we stumble across .., mountpoint or something we belie= ve > to be a symlink, or when the chain reaches fs-specified limit. Said bulk > revalidate should tell how long a prefix had been OK. Permission change > handling would be the painful part here... This seems to just entrench the approach that the dcache is in control and you are trying to contort it in some unnecessary way to meet one more need. In the common case, the rcu_walk version of d_revalidate would be very simp= le and batching them isn't going to buy much. Once you hit a "needs revalidat= e" or anything else that trips up rcu_walk, just hand it all to the filesystem and say "your problem". If the filesystem wants to continue one step at a time, that is easy - there are helpers for that. If the filesystem wants = to send the remainder of the path to the server, it can do that too (being careful of symlinks and mount points of course). Just give the filesystem control for the rare slow path. NeilBrown --Sig_/doXnCWrckpgS=Ndw1Ez=JIf Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIVAwUBVVgHAznsnt1WYoG5AQLEmhAAk5qNraBpstGvKy3W7GbeVplZeV75EAlT lpWE4rdK7rHt2MM4PrRhrsOuqdDer0gEXCT+Iz4/SVkY8aW4zrc3yFIZGCb3jlE7 HBn0a1am/IsJK6SoqmqbS09CunL7pDAcsiMmLxBRDiaSu8lS4crh//8J9zkNvSFp SIda+nN4ndwSaPTKXPebarYydtyc+f+sfjS/r0Bunh5jIgjt7GU1AjE9Kz8Vvocm LQPa3QflKH2Y5Uw48s5exyTh7bali1pMF7uCB4NYpVO653rJG6qWpyLhCHdpWw7P Bjy9v3kgywaTTa0Q4m3XApds078P652YA2aAI6m69pN0n3ee/I4GLA7ZMDDW/3eX ZSS+e4BYP2HKLGre8W4SMxISgoasfrHWikAPx3OyXn2KEhVAyd+w5alBK06UL/ji 3S72G3/81ngVSU9GY8YZnT+PNMr21LM+MnTGllbScz6D6998Ib+2Fc2nh6pdhHHp wfLTwQ+NJE6f53vVMwOM+sr0z9SUqKDGp7CKV00P36H4VIspdiA1IsLe60gAdig0 J7yeTfXuXHlCXmlrInlQ8k1BJcwtULuV2KufMpd+uDex6wTMV1u2keDepxnZkF7o 8fG6pnqXnK141SvI5N/3A1gEza6eedhZK0h1U4uBGb7dyqPyywrvs63a9ikmLSxs Uu+ulK/b5Fk= =SgM2 -----END PGP SIGNATURE----- --Sig_/doXnCWrckpgS=Ndw1Ez=JIf-- -- 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/