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]
Message-ID: <CA+55aFy+NNW1FcJj4Ka2d9u5uvEYOi8xfXH1JnOJ+LSbdtKO-g@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ