Skip to content
  • Al Viro's avatar
    dcache: sort the freeing-without-RCU-delay mess for good. · c939121b
    Al Viro authored
    commit 5467a68c
    
     upstream.
    
    For lockless accesses to dentries we don't have pinned we rely
    (among other things) upon having an RCU delay between dropping
    the last reference and actually freeing the memory.
    
    On the other hand, for things like pipes and sockets we neither
    do that kind of lockless access, nor want to deal with the
    overhead of an RCU delay every time a socket gets closed.
    
    So delay was made optional - setting DCACHE_RCUACCESS in ->d_flags
    made sure it would happen.  We tried to avoid setting it unless
    we knew we need it.  Unfortunately, that had led to recurring
    class of bugs, in which we missed the need to set it.
    
    We only really need it for dentries that are created by
    d_alloc_pseudo(), so let's not bother with trying to be smart -
    just make having an RCU delay the default.  The ones that do
    *not* get it set the replacement flag (DCACHE_NORCU) and we'd
    better use that sparingly.  d_alloc_pseudo() is the only
    such user right now.
    
    FWIW, the race that finally prompted that switch had been
    between __lock_parent() of immediate subdirectory of what's
    currently the root of a disconnected tree (e.g. from
    open-by-handle in progress) racing with d_splice_alias()
    elsewhere picking another alias for the same inode, either
    on outright corrupted fs image, or (in case of open-by-handle
    on NFS) that subdirectory having been just moved on server.
    It's not easy to hit, so the sky is not falling, but that's
    not the first race on similar missed cases and the logics
    for settinf DCACHE_RCUACCESS has gotten ridiculously
    convoluted.
    
    Cc: stable@vger.kernel.org
    Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    c939121b