summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJeff Layton <jlayton@kernel.org>2020-05-20 10:36:07 -0400
committerIlya Dryomov <idryomov@gmail.com>2020-05-27 13:03:57 +0200
commitfb33c114d3ed5bdac230716f5b0a93b56b92a90d (patch)
tree95fabf81bd8b03e209e535b9ed92b1ab3f880ef7
parent890bd0f8997ae6ac0a367dd5146154a3963306dd (diff)
downloadlinux-fb33c114d3ed5bdac230716f5b0a93b56b92a90d.tar.gz
linux-fb33c114d3ed5bdac230716f5b0a93b56b92a90d.tar.bz2
linux-fb33c114d3ed5bdac230716f5b0a93b56b92a90d.zip
ceph: flush release queue when handling caps for unknown inode
It's possible for the VFS to completely forget about an inode, but for it to still be sitting on the cap release queue. If the MDS sends the client a cap message for such an inode, it just ignores it today, which can lead to a stall of up to 5s until the cap release queue is flushed. If we get a cap message for an inode that can't be located, then go ahead and flush the cap release queue. Cc: stable@vger.kernel.org URL: https://tracker.ceph.com/issues/45532 Fixes: 1e9c2eb6811e ("ceph: delete stale dentry when last reference is dropped") Reported-and-Tested-by: Andrej Filipčič <andrej.filipcic@ijs.si> Suggested-by: Yan, Zheng <zyan@redhat.com> Signed-off-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
-rw-r--r--fs/ceph/caps.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c
index 5f3aa4d607de..f1acde6fb9a6 100644
--- a/fs/ceph/caps.c
+++ b/fs/ceph/caps.c
@@ -3991,7 +3991,7 @@ void ceph_handle_caps(struct ceph_mds_session *session,
__ceph_queue_cap_release(session, cap);
spin_unlock(&session->s_cap_lock);
}
- goto done;
+ goto flush_cap_releases;
}
/* these will work even if we don't have a cap yet */