summaryrefslogtreecommitdiff
path: root/fs
diff options
context:
space:
mode:
authorSage Weil <sage@newdream.net>2010-06-21 16:12:26 -0700
committerSage Weil <sage@newdream.net>2010-06-21 16:11:50 -0700
commit17c688c3dfffc274c87be00033da0050bb6eefc0 (patch)
tree1b1586253abf6850c9746235462d71e14e57f243 /fs
parentd69ed05a80f23b25f06e73af9b7e701ce4900edc (diff)
downloadkernel-common-17c688c3dfffc274c87be00033da0050bb6eefc0.tar.gz
kernel-common-17c688c3dfffc274c87be00033da0050bb6eefc0.tar.bz2
kernel-common-17c688c3dfffc274c87be00033da0050bb6eefc0.zip
ceph: delay umount until all mds requests drop inode+dentry refs
This fixes a race between handle_reply finishing an mds request, signalling completion, and then dropping the request structing and its dentry+inode refs, and pre_umount function waiting for requests to finish before letting the vfs tear down the dcache. If umount was delayed waiting for mds requests, we could race and BUG in shrink_dcache_for_umount_subtree because of a slow dput. This delays umount until the msgr queue flushes, which means handle_reply will exit and will have dropped the ceph_mds_request struct. I'm assuming the VFS has already ensured that its calls have all completed and those request refs have thus been dropped as well (I haven't seen that race, at least). Signed-off-by: Sage Weil <sage@newdream.net>
Diffstat (limited to 'fs')
-rw-r--r--fs/ceph/mds_client.c6
1 files changed, 6 insertions, 0 deletions
diff --git a/fs/ceph/mds_client.c b/fs/ceph/mds_client.c
index 1766947fc07a..3ab79f6c4ce8 100644
--- a/fs/ceph/mds_client.c
+++ b/fs/ceph/mds_client.c
@@ -2783,6 +2783,12 @@ void ceph_mdsc_pre_umount(struct ceph_mds_client *mdsc)
drop_leases(mdsc);
ceph_flush_dirty_caps(mdsc);
wait_requests(mdsc);
+
+ /*
+ * wait for reply handlers to drop their request refs and
+ * their inode/dcache refs
+ */
+ ceph_msgr_flush();
}
/*