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:	Sat, 16 May 2015 21:04:34 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	NeilBrown <neilb@...e.de>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	Andreas Dilger <adilger@...ger.ca>,
	Dave Chinner <david@...morbit.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: [RFC][PATCHSET v3] non-recursive pathname resolution & RCU symlinks

On Sat, May 16, 2015 at 8:48 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Sorry, but that really is how it is. NFS isn't special enough for some
> badly designed lookup models to matter one whit.

Btw, it's not just about performance, although the whole "we can do
cached lookups without ever having to et the filesystem involved" is a
big deal.

It's about getting fundamental concpets like mount points etc right,
it's about all those those things that the filesystem really doesn't
know about, and _cannot_ sanely know about.

It's now about things like overlayfs etc, all those things.

So the filesystem really isn't in control. Never will be. The
filesystem is at the mercy of (extended) unix semantics that are
bigger than the filesystem.

This is true of IO too. The filesystem does have a bit more
flexibility, but in the end, you have to do the readpage thing,
because it's the only way you'll get mmap. The filesystem isn't really
in control there either, there are strict rules for what it has to do
in order to have reasonable coherent mmap semantics.

So the vfs layer often does have a "library" approach, because
filesystems may do things in very different ways. But at the same
time, the vfs layer really *is* in control, because it's the vfs layer
that enforces certain basic semantics. So the dcache very much isn't
just sme "slave cache" that you choose to use and is at the control of
the filesystem. Like the page cache, you don't get a choice, because
you aren't in charge.

When somebody does a lookup of a filename, it is not a "pass this
filename to the filesystem". It very much *is* a
component-by-component lookup. And in the *vast* majority of the
cases, the cached lookup when you don't even get asked is absolutely
the right thing to do, and doing anything else wouldn't just be wrong,
it would be completely and utterly stupid.

And the fact that somebody doesn't understand that, and has designed
bad extensions to do multi-component lookup, isn't actually an
argument against the dcache. It's just an argument for "people make
bad intterfaces because they hack things up and don't understand
things".

               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/