summaryrefslogtreecommitdiffstats
path: root/fs/filesystems.c
diff options
context:
space:
mode:
authorJ. Bruce Fields <bfields@redhat.com>2014-02-14 17:35:37 -0500
committerAl Viro <viro@zeniv.linux.org.uk>2014-08-07 14:40:10 -0400
commit1a0a397e41cb1bf70cfe45fd0eeff08c7c501ec0 (patch)
treec02c59997a3849bb1bfdcc3ac371bb1e4d2f81bc /fs/filesystems.c
parentda093a9b76efca0a7a217af538929e1ecb204466 (diff)
downloadlinux-1a0a397e41cb1bf70cfe45fd0eeff08c7c501ec0.tar.gz
linux-1a0a397e41cb1bf70cfe45fd0eeff08c7c501ec0.tar.bz2
linux-1a0a397e41cb1bf70cfe45fd0eeff08c7c501ec0.zip
dcache: d_obtain_alias callers don't all want DISCONNECTED
There are a few d_obtain_alias callers that are using it to get the root of a filesystem which may already have an alias somewhere else. This is not the same as the filehandle-lookup case, and none of them actually need DCACHE_DISCONNECTED set. It isn't really a serious problem, but it would really be clearer if we reserved DCACHE_DISCONNECTED for those cases where it's actually needed. In the btrfs case this was causing a spurious printk from nfsd/nfsfh.c:fh_verify when it found an unexpected DCACHE_DISCONNECTED dentry. Josef worked around this by unsetting DCACHE_DISCONNECTED manually in 3a0dfa6a12e "Btrfs: unset DCACHE_DISCONNECTED when mounting default subvol", and this replaces that workaround. Cc: Josef Bacik <jbacik@fb.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'fs/filesystems.c')
0 files changed, 0 insertions, 0 deletions