• NeilBrown's avatar
    VFS: close race between getcwd() and d_move() · db470ce8
    NeilBrown authored
    
    [ Upstream commit 61647823 ]
    
    d_move() will call __d_drop() and then __d_rehash()
    on the dentry being moved.  This creates a small window
    when the dentry appears to be unhashed.  Many tests
    of d_unhashed() are made under ->d_lock and so are safe
    from racing with this window, but some aren't.
    In particular, getcwd() calls d_unlinked() (which calls
    d_unhashed()) without d_lock protection, so it can race.
    
    This races has been seen in practice with lustre, which uses d_move() as
    part of name lookup.  See:
       https://jira.hpdd.intel.com/browse/LU-9735
    It could race with a regular rename(), and result in ENOENT instead
    of either the 'before' or 'after' name.
    
    The race can be demonstrated with a simple program which
    has two threads, one renaming a directory back and forth
    while another calls getcwd() within that directory: it should never
    fail, but does.  See:
      https://patchwork.kernel.org/patch/9455345/
    
    We could fix this race by taking d_lock and rechecking when
    d_unhashed() reports true.  Alternately when can remove the window,
    which is the approach this patch takes.
    
    ___d_drop() is introduce which does *not* clear d_hash.pprev
    so the dentry still appears to be hashed.  __d_drop() calls
    ___d_drop(), then clears d_hash.pprev.
    __d_move() now uses ___d_drop() and only clears d_hash.pprev
    when not rehashing.
    Signed-off-by: default avatarNeilBrown <neilb@suse.com>
    Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    db470ce8
dcache.c 94.8 KB