Message-ID: <20150514033040.GF7232@ZenIV.linux.org.uk>
Date:	Thu, 14 May 2015 04:30:40 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Christoph Hellwig <hch@...radead.org>,
	Neil Brown <neilb@...e.de>
Subject: Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU
 symlinks

On Wed, May 13, 2015 at 06:39:53PM -0700, Linus Torvalds wrote:
> On Wed, May 13, 2015 at 3:25 PM, Al Viro <viro@...iv.linux.org.uk> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists