• Al Viro's avatar
    do d_instantiate/unlock_new_inode combinations safely · 2d2d3f1e
    Al Viro authored
    commit 1e2e547a upstream.
    
    For anything NFS-exported we do _not_ want to unlock new inode
    before it has grown an alias; original set of fixes got the
    ordering right, but missed the nasty complication in case of
    lockdep being enabled - unlock_new_inode() does
    	lockdep_annotate_inode_mutex_key(inode)
    which can only be done before anyone gets a chance to touch
    ->i_mutex.  Unfortunately, flipping the order and doing
    unlock_new_inode() before d_instantiate() opens a window when
    mkdir can race with open-by-fhandle on a guessed fhandle, leading
    to multiple aliases for a directory inode and all the breakage
    that follows from that.
    
    	Correct solution: a new primitive (d_instantiate_new())
    combining these two in the right order - lockdep annotate, then
    d_instantiate(), then the rest of unlock_new_inode().  All
    combinations of d_instantiate() with unlock_new_inode() should
    be converted to that.
    
    Cc: stable@kernel.org	# 2.6.29 and later
    Tested-by: default avatarMike Marshall <hubcap@omnibond.com>
    Reviewed-by: default avatarAndreas Dilger <adilger@dilger.ca>
    Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    2d2d3f1e
inode.c 284 KB