Эх сурвалжийг харах

ceph: handle race between vmtruncate and queuing cap snap

It's possible that we create a cap snap while there is pending
vmtruncate (truncate hasn't been processed by worker thread).
We should truncate dirty pages beyond capsnap->size in that case.

Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Yan, Zheng 8 жил өмнө
parent
commit
c8fd0d37f8
1 өөрчлөгдсөн 12 нэмэгдсэн , 1 устгасан
  1. 12 1
      fs/ceph/inode.c

+ 12 - 1
fs/ceph/inode.c

@@ -1833,9 +1833,20 @@ retry:
 	 * possibly truncate them.. so write AND block!
 	 * possibly truncate them.. so write AND block!
 	 */
 	 */
 	if (ci->i_wrbuffer_ref_head < ci->i_wrbuffer_ref) {
 	if (ci->i_wrbuffer_ref_head < ci->i_wrbuffer_ref) {
+		struct ceph_cap_snap *capsnap;
+		to = ci->i_truncate_size;
+		list_for_each_entry(capsnap, &ci->i_cap_snaps, ci_item) {
+			// MDS should have revoked Frw caps
+			WARN_ON_ONCE(capsnap->writing);
+			if (capsnap->dirty_pages && capsnap->size > to)
+				to = capsnap->size;
+		}
+		spin_unlock(&ci->i_ceph_lock);
 		dout("__do_pending_vmtruncate %p flushing snaps first\n",
 		dout("__do_pending_vmtruncate %p flushing snaps first\n",
 		     inode);
 		     inode);
-		spin_unlock(&ci->i_ceph_lock);
+
+		truncate_pagecache(inode, to);
+
 		filemap_write_and_wait_range(&inode->i_data, 0,
 		filemap_write_and_wait_range(&inode->i_data, 0,
 					     inode->i_sb->s_maxbytes);
 					     inode->i_sb->s_maxbytes);
 		goto retry;
 		goto retry;