do d_instantiate/unlock_new_inode combinations safely
authorAl Viro <viro@zeniv.linux.org.uk>
Fri, 4 May 2018 12:23:01 +0000 (08:23 -0400)
committerAl Viro <viro@zeniv.linux.org.uk>
Fri, 11 May 2018 19:36:37 +0000 (15:36 -0400)
commit1e2e547a93a00ebc21582c06ca3c6cfea2a309ee
treee31468774e0543997a15daa0409ef79a02d1438c
parentd7760d638b140d53c6390a2fbee9b06460b43e9e
do d_instantiate/unlock_new_inode combinations safely

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: Mike Marshall <hubcap@omnibond.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
14 files changed:
fs/btrfs/inode.c
fs/dcache.c
fs/ecryptfs/inode.c
fs/ext2/namei.c
fs/ext4/namei.c
fs/f2fs/namei.c
fs/jffs2/dir.c
fs/jfs/namei.c
fs/nilfs2/namei.c
fs/orangefs/namei.c
fs/reiserfs/namei.c
fs/udf/namei.c
fs/ufs/namei.c
include/linux/dcache.h