linux-kernel - Re: [PATCH 3/3] VFS: close race between getcwd() and d

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+55aFyhnZBK2uZsWNR75Dwx=Wc1HRvnK9qc5OB=1vAdh_UVOg@mail.gmail.com>
Date:   Fri, 10 Nov 2017 11:52:17 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     NeilBrown <neilb@...e.com>
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] VFS: close race between getcwd() and d_move()

On Thu, Nov 9, 2017 at 8:45 PM, NeilBrown <neilb@...e.com> wrote:
>
> However your description of what it was that you didn't like gave me an
> idea - I can take the same approach as my original, but not pass flags
> around.
> I quite like how this turned out.
> Dropping the BUG_ON() in d_rehash() isn't ideal, maybe we could add
> ___d_rehash() without the BUG_ON() and call that from __d_rehash?

This looks more palatable to me, yes.

It still worries me a bit that we end up having that dangling pprev
pointer despite having dropped the hash list lock, but as long as
nobody uses it for anything but that "is it hashed" test without
taking the dentry lock, it all *should* be safe.

Please fix the whitespace, though. This is not how we do function definitions:

    void __d_drop(struct dentry *dentry) {

but otherwise I think this patch is acceptable.

Still want commentary from Al (and preferably going through his vfs
tree for 4.15 or whatever).

             Linus