]> git-server-git.apps.pok.os.sepia.ceph.com Git - ceph-client.git/commit
ceph: don't set req->r_locked_dir in ceph_d_revalidate historic/wip-jlayton-18041
authorJeff Layton <jlayton@redhat.com>
Wed, 30 Nov 2016 20:56:46 +0000 (15:56 -0500)
committerJeff Layton <jlayton@redhat.com>
Fri, 2 Dec 2016 14:16:25 +0000 (09:16 -0500)
commite38ee67bc89f6fc40d8a35e265ae82a07a8f37bc
treec0d1cf3d2d77b855c8c136e79f633ef339cbf90f
parentef650cbcecc6cfb557fd2570b22f83e4d7f7a24d
ceph: don't set req->r_locked_dir in ceph_d_revalidate

This function sets req->r_locked_dir which is supposed to indicate to
ceph_fill_trace that the parent's i_rwsem is locked for write.
Unfortunately, there is no guarantee that the dir will be locked when
d_revalidate is called, so we really don't want ceph_fill_trace to do
any dcache manipulation from this context. Clear req->r_locked_dir since
it's clearly not safe to do that.

What we really want to know with d_revalidate is whether the dentry
still points to the same inode. ceph_fill_trace installs a pointer to
the inode in req->r_target_inode, so we can just compare that to
d_inode(dentry) to see if it's the same one after the lookup.

Also, since we aren't generally interested in the parent here, we can
switch to using a GETATTR to hint that to the MDS, which also means that
we only need to reserve one cap.

Finally, just remove the d_unhashed check. That's really outside the
purview of a filesystem's d_revalidate. If the thing became unhashed
while we're checking it, then that's up to the VFS to handle anyway.

Fixes: 200fd27c8fa2 (ceph: use lookup request to revalidate dentry)
Reported-by: Donatas Abraitis <donatas.abraitis@gmail.com>
Cc: stable@vger.kernel.org # v4.6+
Signed-off-by: Jeff Layton <jlayton@redhat.com>
fs/ceph/dir.c