linux-kernel - Re: [git pull] vfs fixes

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+55aFxevVjhjnxMoLY9OtpGc81ZNUYV4NcFN0VPX7pQY1pxXQ@mail.gmail.com>
Date:   Sun, 2 Apr 2017 17:58:41 -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>
Subject: Re: [git pull] vfs fixes

On Sun, Apr 2, 2017 at 5:43 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Do you have any objections against the following (still untested) variant?
> I don't see any point in checking for flags & LOOKUP_RCU in case of !*s -
> flags is in register at that point, so...

Looks sane to me.

I had to go and double-check that "DCACHE_DIRECTORY_TYPE" is what
d_can_lookup() actually checks, so _that_ part is perhaps a bit
subtle, and might be worth noting in that comment that you edited.

So the real "rule" ends up being that we only ever look up things from
dentries of type DCACHE_DIRECTORY_TYPE set, and those had better have
DCACHE_RCUACCESS bit set.

And the only reason path_init() only checks it for that case is that
nd->root and nd->pwd both have to be of type d_can_lookup().

Do we check that when we set it? I hope/assume we do.

                      Linus