summaryrefslogtreecommitdiff
path: root/security
diff options
context:
space:
mode:
authorMiklos Szeredi <mszeredi@suse.cz>2012-05-21 19:30:20 +0400
committerAl Viro <viro@zeniv.linux.org.uk>2012-06-01 20:12:02 +0400
commit0ef97dcfce4179a2eba046b855ee2f91d6f1b414 (patch)
treed5a29275a427dafd8fce0131b58f215c6252d3e2 /security
parent16b1c1cd71176ab0a76b26818fbf12db9183ed57 (diff)
downloadlinux-0ef97dcfce4179a2eba046b855ee2f91d6f1b414.tar.xz
nfs: don't open in ->d_revalidate
NFSv4 can't do reliable opens in d_revalidate, since it cannot know whether a mount needs to be followed or not. It does check d_mountpoint() on the dentry, which can result in a weird error if the VFS found that the mount does not in fact need to be followed, e.g.: # mount --bind /mnt/nfs /mnt/nfs-clone # echo something > /mnt/nfs/tmp/bar # echo x > /tmp/file # mount --bind /tmp/file /mnt/nfs-clone/tmp/bar # cat /mnt/nfs/tmp/bar cat: /mnt/nfs/tmp/bar: Not a directory Which should, by any sane filesystem, result in "something" being printed. So instead do the open in f_op->open() and in the unlikely case that the cached dentry turned out to be invalid, drop the dentry and return EOPENSTALE to let the VFS retry. Signed-off-by: Miklos Szeredi <mszeredi@suse.cz> CC: Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'security')
0 files changed, 0 insertions, 0 deletions