Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754854AbbENDao (ORCPT ); Wed, 13 May 2015 23:30:44 -0400 Received: from zeniv.linux.org.uk ([195.92.253.2]:46199 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753839AbbENDan (ORCPT ); Wed, 13 May 2015 23:30:43 -0400 Date: Thu, 14 May 2015 04:30:40 +0100 From: Al Viro To: Linus Torvalds Cc: Linux Kernel Mailing List , linux-fsdevel , Christoph Hellwig , Neil Brown Subject: Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks Message-ID: <20150514033040.GF7232@ZenIV.linux.org.uk> References: <20150505052205.GS889@ZenIV.linux.org.uk> <20150511180650.GA4147@ZenIV.linux.org.uk> <20150513222533.GA24192@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3572 Lines: 68 On Wed, May 13, 2015 at 06:39:53PM -0700, Linus Torvalds wrote: > On Wed, May 13, 2015 at 3:25 PM, Al Viro wrote: > > More on top of the current vfs.git#for-next (== the posted patchset > > with a couple of fixes): more fs/namei.c reorganization and stack footprint > > reduction (below 1Kb now). One interesting piece of that is that we don't > > touch current->fs->lock anymore - unlazy_walk() used to, but now we can > > get rid of that. > > Ok. I don't see anything wrong here, but I have to admit that I'm also > at the point where I go "maybe this area should calm down a bit", and > where I'd prefer to not see more long patch-series. Even if most of > the patches seem to be fairly mechanical code movement and cleanup and > preparation, mistakes happen, and I just get worried. > > So I think the series is good, but in particular if you're planning on > some more core changes (ie your "act on filename" callback thing), I > would really prefer that we stop at this point for the 4.2 window, and > make sure it's all stable. *nod* It had been a fun three weeks, but at that point all low-hanging fruits are gone. There is more stuff visible there (lazy stat(), offloading automounts via schedule_work(), perhaps RCU handling of non-fast symlinks), but that'll take a lot more serious plotting[1] before it gets to the stage when it can be implemented. In particular, automounts will require discussing what exactly in the process' state is used for those - both with autofs/NFS/AFS/CIFS folks and with Eric (what netns should be used when we are crossing an NFSv4 referral point? Should it come from the NFS mount we'd found the referral on, or from the process that has run across it? There'd been a series from Ian around the interplay of autofs with namespaces, and IIRC it stepped into similar-sounding areas; it'll need to be looked into, etc.) I doubt that we'll get it sorted out before 4.2, and this kind of stuff *does* need exposure in -testing, as well as public review, so such continuations are clear 4.3 fodder. I hope to get it figured out by the time 4.3-rc1 comes, so that it could be dealt with early in the next cycle, but for now I'm planning to pull the current #link_path_walk into #for-next and let it soak there. Especially since there are other pending piles of joy elsewhere - handling of d_move()-messed vfsmounts, for starters ;-/ > And then your callback thing could be for 4.3. > > That said, I'm not entirely convinced about a callback approach for > stat() and friends. I suspect only stat() is really critical enough to > warrant the whole "let's do it all in RCU mode", and if there's only > one case, then there's no need for the (*act) indirection - might as > well hardcode it. Maybe... I'd like to see the profiles, TBH - especially getxattr() and access() frequency on various loads. Sure, make(1) and cc(1) really care about stat() very much, but I wouldn't be surprised if something like httpd or samba would be hitting getxattr() a lot... > But feel free to convince me. Again, I'd really prefer that to be > after the current work has been in a stable release and a well tested > base, though. No arguments here... [1] as in "which shitpiles are we likely to step into on the way there and how far would detours take us" -- 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/