From: Dave Chinner <david@fromorbit.com>
To: linux-xfs@vger.kernel.org
Subject: [PATCH 7/7] xfs: flush removing page cache in xfs_reflink_remap_prep
Date: Tue, 20 Nov 2018 08:04:59 +1100 [thread overview]
Message-ID: <20181119210459.8506-8-david@fromorbit.com> (raw)
In-Reply-To: <20181119210459.8506-1-david@fromorbit.com>
From: Dave Chinner <dchinner@redhat.com>
On a sub-page block size filesystem, fsx is failing with a data
corruption after a series of operations involving copying a file
with the destination offset beyond EOF of the destination of the file:
8093(157 mod 256): TRUNCATE DOWN from 0x7a120 to 0x50000 ******WWWW
8094(158 mod 256): INSERT 0x25000 thru 0x25fff (0x1000 bytes)
8095(159 mod 256): COPY 0x18000 thru 0x1afff (0x3000 bytes) to 0x2f400
8096(160 mod 256): WRITE 0x5da00 thru 0x651ff (0x7800 bytes) HOLE
8097(161 mod 256): COPY 0x2000 thru 0x5fff (0x4000 bytes) to 0x6fc00
The second copy here is beyond EOF, and it is to sub-page (4k) but
block aligned (1k) offset. The clone runs the EOF zeroing, landing
in a pre-existing post-eof delalloc extent. This zeroes the post-eof
extents in the page cache just fine, dirtying the pages correctly.
The problem is that xfs_reflink_remap_prep() now truncates the page
cache over the range that it is copying it to, and rounds that down
to cover the entire start page. This removes the dirty page over the
delalloc extent from the page cache without having written it back.
Hence later, when the page cache is flushed, the page at offset
0x6f000 has not been written back and hence exposes stale data,
which fsx trips over less than 10 operations later.
Fix this by changing xfs_reflink_remap_prep() to use
xfs_flush_unmap_range().
Signed-off-by: Dave Chinner <dchinner@redhat.com>
---
fs/xfs/xfs_bmap_util.c | 2 +-
fs/xfs/xfs_bmap_util.h | 3 +++
fs/xfs/xfs_reflink.c | 17 +++++++++++++----
3 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
index cc7a0d47c529..3e66cf0520a9 100644
--- a/fs/xfs/xfs_bmap_util.c
+++ b/fs/xfs/xfs_bmap_util.c
@@ -1042,7 +1042,7 @@ xfs_unmap_extent(
goto out_unlock;
}
-static int
+int
xfs_flush_unmap_range(
struct xfs_inode *ip,
xfs_off_t offset,
diff --git a/fs/xfs/xfs_bmap_util.h b/fs/xfs/xfs_bmap_util.h
index 87363d136bb6..7a78229cf1a7 100644
--- a/fs/xfs/xfs_bmap_util.h
+++ b/fs/xfs/xfs_bmap_util.h
@@ -80,4 +80,7 @@ int xfs_bmap_count_blocks(struct xfs_trans *tp, struct xfs_inode *ip,
int whichfork, xfs_extnum_t *nextents,
xfs_filblks_t *count);
+int xfs_flush_unmap_range(struct xfs_inode *ip, xfs_off_t offset,
+ xfs_off_t len);
+
#endif /* __XFS_BMAP_UTIL_H__ */
diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c
index ecdb086bc23e..a41590b7c229 100644
--- a/fs/xfs/xfs_reflink.c
+++ b/fs/xfs/xfs_reflink.c
@@ -1351,10 +1351,19 @@ xfs_reflink_remap_prep(
if (ret)
goto out_unlock;
- /* Zap any page cache for the destination file's range. */
- truncate_inode_pages_range(&inode_out->i_data,
- round_down(pos_out, PAGE_SIZE),
- round_up(pos_out + *len, PAGE_SIZE) - 1);
+ /*
+ * If pos_out > EOF, we make have dirtied blocks between EOF and
+ * pos_out. In that case, we need to extend the flush and unmap to cover
+ * from EOF to the end of the copy length.
+ */
+ if (pos_out > XFS_ISIZE(dest)) {
+ loff_t flen = *len + (pos_out - XFS_ISIZE(dest));
+ ret = xfs_flush_unmap_range(dest, XFS_ISIZE(dest), flen);
+ } else {
+ ret = xfs_flush_unmap_range(dest, pos_out, *len);
+ }
+ if (ret)
+ goto out_unlock;
return 1;
out_unlock:
--
2.19.1
next prev parent reply other threads:[~2018-11-20 7:31 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-19 21:04 [PATCH 0/7] xfs: various fixes for 4.20 Dave Chinner
2018-11-19 21:04 ` [PATCH 1/7] xfs: zero length symlinks are not valid Dave Chinner
2018-11-20 8:12 ` Christoph Hellwig
2018-11-20 13:44 ` Brian Foster
2018-11-20 21:19 ` Dave Chinner
2018-11-21 12:01 ` Brian Foster
2018-11-19 21:04 ` [PATCH 2/7] xfs: uncached buffer tracing needs to print bno Dave Chinner
2018-11-20 8:12 ` Christoph Hellwig
2018-11-20 22:46 ` Darrick J. Wong
2018-11-19 21:04 ` [PATCH 3/7] xfs: fix transient reference count error in xfs_buf_resubmit_failed_buffers Dave Chinner
2018-11-20 8:13 ` Christoph Hellwig
2018-11-20 22:48 ` Darrick J. Wong
2018-11-19 21:04 ` [PATCH 4/7] xfs: finobt AG reserves don't consider last AG can be a runt Dave Chinner
2018-11-20 8:14 ` Christoph Hellwig
2018-11-20 22:49 ` Darrick J. Wong
2018-11-19 21:04 ` [PATCH 5/7] xfs: extent shifting doesn't fully invalidate page cache Dave Chinner
2018-11-20 8:18 ` Christoph Hellwig
2018-11-20 22:53 ` Darrick J. Wong
2018-11-19 21:04 ` [PATCH 6/7] xfs: don't ENOSPC on writeback when punching holes Dave Chinner
2018-11-20 8:20 ` Christoph Hellwig
2018-11-20 9:50 ` Dave Chinner
2018-11-20 16:28 ` Christoph Hellwig
2018-11-20 21:00 ` Dave Chinner
2018-11-21 18:09 ` Darrick J. Wong
2018-11-22 2:31 ` Dave Chinner
2018-11-19 21:04 ` Dave Chinner [this message]
2018-11-20 8:32 ` [PATCH 7/7] xfs: flush removing page cache in xfs_reflink_remap_prep Christoph Hellwig
2018-11-20 22:56 ` Darrick J. Wong
2018-11-20 6:36 ` [PATCH 8/7] xfs: delalloc -> unwritten COW fork allocation can go wrong Dave Chinner
2018-11-20 13:45 ` Brian Foster
2018-11-20 16:33 ` Christoph Hellwig
2018-11-20 21:08 ` Dave Chinner
2018-11-20 16:32 ` Christoph Hellwig
2018-11-20 22:58 ` Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181119210459.8506-8-david@fromorbit.com \
--to=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).