linux-kernel - Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 13 May 2015 18:39:53 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
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 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.

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.

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.

                     Linus
--
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/