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]

Message-ID: <20150518093907.18330172@notabene.brown>
Date:	Mon, 18 May 2015 09:39:07 +1000
From:	NeilBrown <neilb@...e.de>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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 Sun, 17 May 2015 11:55:35 +0100 Al Viro <viro@...IV.linux.org.uk> wrote:

> As for Neil's point re do_last() and friends being much too convoluted - yes,
> they are.  And it's not a result of trying to shoehorn everything in one
> model.  "Just let NFS have at it" as soon as we reach do_last() won't make
> things any simpler, unfortunately - we'll end up with the same convoluted
> mess copied in a bunch of filesystems, each with bugs of its own.

There is no reason to be so gloomy.
The VFS would provide a generic_do_last() (or whatever) which handles
everything correctly for local filesystems which keep the dcache precisely
consistent and use it for all the valuable locking it can provide.
generic_to_last() would call into other filesystem entry points just like the
current do_last() does.  It wouldn't bother with 'revalidation' though.

Then there might be a "generic_network_do_last()" which does minimal if any
checking because the server will do all that, and just calls back to the
filesystem depending on which particular operation is happening - mkdir, or
unlink or whatever.

Filesystem developers are both very clever and (I assume) very lazy.  If you
provide them with tools that work and are easy to understand, they will much
rather use them than try to implement their own.  This is why the page cache
is such a success.

The more I think about this, the more it seems to me that having a dentry
that can be "unknown", or as you put it "in-lookup" is
potentially transformational.

Pathname lookup just always returns the dentry of the final component (plus
vfsmount), but that final component might be "unknown".

Then the various "last" steps are quite separate and each work with this
dentry.  They unlink or mkdir or mknod or lookup or create or whatever.
There are probably races that make this a little more complicated than I am
hoping, and rename will doubtlessly be the most interesting.  But it feels
like a good direction.

That is all a long way off of course.  Even just getting a "in-lookup" dentry
and starting to explore what can be done with that would be a very positive
step I think.

Thanks,
NeilBrown

Content of type "application/pgp-signature" skipped