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: <CA+55aFyxmXNrBG29pM3JJY6F_mOx_EXAbAKPoDyapge4i+87AA@mail.gmail.com>
Date:	Sun, 17 May 2015 21:20:56 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	NeilBrown <neilb@...e.de>, 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, May 17, 2015 at 8:42 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> "Rest of the path" makes no sense, obviously.  "More of the path" (and _not_
> as a string, TYVM - we have those components in ->d_name.name of dentries we
> want revalidated [..])

For revalidate, yes we kind of have them as dentries. I say kind of,
because it may be that we're only revalidating a directory in the
middle, and the rest of the path will be all new lookups, and we don't
have that part as dentries at all. But nobody is going to care about
"revalidate" for those.

HOWEVER.

We haven't actually walked/parsed the rest of the pathname yet at that
point, and we generally probably shouldn't, since we don't know if the
filesystem really is going to care. Why do extra work that may not be
useful?

So if we really do want to do it, and some filesystem cares enough, I
think we actually should just pass it in as a string, and then have a
helper function to say "ok, filesystem, if you want to revalidate the
rest of the path, use this function to turn the hinting string into
more dentries".

Because I don't think it's worth doing up-front if it's not clear that
the filesystem is going to care.

For example, the /proc filesystem uses d_revalidate() to re-check the
pid entries. That does *not* mean that it wants the rest of the
dentries pre-parsed at all. So by all means give it a "const char
*hint" for the rest, but it's going to just ignore it anyway, so don't
wast parsing it as "these will be the following dentries we will ask
you to revalidate".

So I do think that "const char *hint" might be the right thing to pass
down if we really care about this sufficiently. Both to revalidate and
to lookup().

We currently have that "rest" in lookup_slow() as

        nd->last.name + hashlen_len(nd->last.hash_len)

and we could just pass that down to lookup_dcache (which does
revalidate) and lookup_real() (which does the actual ->lookup).

But I guess we could just save off 'name' into a new field in
nameidata in link_path_walk() after we've removed the slashes? I don't
know if it matters. We can mask off the slashes again if/when people
want to use the hint, after all.

                   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/