• Al Viro's avatar
    do d_instantiate/unlock_new_inode combinations safely · 2d2d3f1e
    Al Viro authored
    commit 1e2e547a93a00ebc21582c06ca3c6cfea2a309ee 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: 's avatarMike Marshall <hubcap@omnibond.com>
    Reviewed-by: 's avatarAndreas Dilger <adilger@dilger.ca>
    Signed-off-by: 's avatarAl Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    2d2d3f1e
Name
Last commit
Last update
..
Kconfig Loading commit data...
Makefile Loading commit data...
crypto.c Loading commit data...
debug.c Loading commit data...
dentry.c Loading commit data...
ecryptfs_kernel.h Loading commit data...
file.c Loading commit data...
inode.c Loading commit data...
keystore.c Loading commit data...
kthread.c Loading commit data...
main.c Loading commit data...
messaging.c Loading commit data...
miscdev.c Loading commit data...
mmap.c Loading commit data...
read_write.c Loading commit data...
super.c Loading commit data...