From: Chandan Babu R <chandan.babu@oracle.com>
To: djwong@kernel.org
Cc: chandan.babu@oracle.com, linux-xfs@vger.kernel.org,
amir73il@gmail.com, leah.rumancik@gmail.com
Subject: [PATCH 5.4 CANDIDATE V2 13/17] xfs: stabilize insert range start boundary to avoid COW writeback race
Date: Tue, 20 Sep 2022 18:18:32 +0530 [thread overview]
Message-ID: <20220920124836.1914918-14-chandan.babu@oracle.com> (raw)
In-Reply-To: <20220920124836.1914918-1-chandan.babu@oracle.com>
From: Brian Foster <bfoster@redhat.com>
commit d0c2204135a0cdbc607c94c481cf1ccb2f659aa7 upstream.
generic/522 (fsx) occasionally fails with a file corruption due to
an insert range operation. The primary characteristic of the
corruption is a misplaced insert range operation that differs from
the requested target offset. The reason for this behavior is a race
between the extent shift sequence of an insert range and a COW
writeback completion that causes a front merge with the first extent
in the shift.
The shift preparation function flushes and unmaps from the target
offset of the operation to the end of the file to ensure no
modifications can be made and page cache is invalidated before file
data is shifted. An insert range operation then splits the extent at
the target offset, if necessary, and begins to shift the start
offset of each extent starting from the end of the file to the start
offset. The shift sequence operates at extent level and so depends
on the preparation sequence to guarantee no changes can be made to
the target range during the shift. If the block immediately prior to
the target offset was dirty and shared, however, it can undergo
writeback and move from the COW fork to the data fork at any point
during the shift. If the block is contiguous with the block at the
start offset of the insert range, it can front merge and alter the
start offset of the extent. Once the shift sequence reaches the
target offset, it shifts based on the latest start offset and
silently changes the target offset of the operation and corrupts the
file.
To address this problem, update the shift preparation code to
stabilize the start boundary along with the full range of the
insert. Also update the existing corruption check to fail if any
extent is shifted with a start offset behind the target offset of
the insert range. This prevents insert from racing with COW
writeback completion and fails loudly in the event of an unexpected
extent shift.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Acked-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Chandan Babu R <chandan.babu@oracle.com>
---
fs/xfs/libxfs/xfs_bmap.c | 2 +-
fs/xfs/xfs_bmap_util.c | 12 ++++++++++++
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c
index e7fa611887ad..8d035842fe51 100644
--- a/fs/xfs/libxfs/xfs_bmap.c
+++ b/fs/xfs/libxfs/xfs_bmap.c
@@ -5876,7 +5876,7 @@ xfs_bmap_insert_extents(
XFS_WANT_CORRUPTED_GOTO(mp, !isnullstartblock(got.br_startblock),
del_cursor);
- if (stop_fsb >= got.br_startoff + got.br_blockcount) {
+ if (stop_fsb > got.br_startoff) {
ASSERT(0);
error = -EFSCORRUPTED;
goto del_cursor;
diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c
index d6d78e127625..113bed28bc31 100644
--- a/fs/xfs/xfs_bmap_util.c
+++ b/fs/xfs/xfs_bmap_util.c
@@ -1167,6 +1167,7 @@ xfs_prepare_shift(
struct xfs_inode *ip,
loff_t offset)
{
+ struct xfs_mount *mp = ip->i_mount;
int error;
/*
@@ -1179,6 +1180,17 @@ xfs_prepare_shift(
return error;
}
+ /*
+ * Shift operations must stabilize the start block offset boundary along
+ * with the full range of the operation. If we don't, a COW writeback
+ * completion could race with an insert, front merge with the start
+ * extent (after split) during the shift and corrupt the file. Start
+ * with the block just prior to the start to stabilize the boundary.
+ */
+ offset = round_down(offset, 1 << mp->m_sb.sb_blocklog);
+ if (offset)
+ offset -= (1 << mp->m_sb.sb_blocklog);
+
/*
* Writeback and invalidate cache for the remainder of the file as we're
* about to shift down every extent from offset to EOF.
--
2.35.1
next prev parent reply other threads:[~2022-09-20 12:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-20 12:48 [PATCH 5.4 CANDIDATE V2 00/17] xfs stable candidate patches for 5.4.y (from v5.5) Chandan Babu R
2022-09-20 12:48 ` [PATCH 5.4 CANDIDATE V2 01/17] MAINTAINERS: add Chandan as xfs maintainer for 5.4.y Chandan Babu R
2022-09-20 12:48 ` [PATCH 5.4 CANDIDATE V2 02/17] iomap: iomap that extends beyond EOF should be marked dirty Chandan Babu R
2022-09-20 12:48 ` [PATCH 5.4 CANDIDATE V2 03/17] xfs: replace -EIO with -EFSCORRUPTED for corrupt metadata Chandan Babu R
2022-09-20 12:48 ` [PATCH 5.4 CANDIDATE V2 04/17] xfs: slightly tweak an assert in xfs_fs_map_blocks Chandan Babu R
2022-09-20 12:48 ` [PATCH 5.4 CANDIDATE V2 05/17] xfs: add missing assert in xfs_fsmap_owner_from_rmap Chandan Babu R
2022-09-20 12:48 ` [PATCH 5.4 CANDIDATE V2 06/17] xfs: range check ri_cnt when recovering log items Chandan Babu R
2022-09-20 12:48 ` [PATCH 5.4 CANDIDATE V2 07/17] xfs: attach dquots and reserve quota blocks during unwritten conversion Chandan Babu R
2022-09-20 12:48 ` [PATCH 5.4 CANDIDATE V2 08/17] xfs: Fix deadlock between AGI and AGF when target_ip exists in xfs_rename() Chandan Babu R
2022-09-20 12:48 ` [PATCH 5.4 CANDIDATE V2 09/17] xfs: convert EIO to EFSCORRUPTED when log contents are invalid Chandan Babu R
2022-09-20 12:48 ` [PATCH 5.4 CANDIDATE V2 10/17] xfs: constify the buffer pointer arguments to error functions Chandan Babu R
2022-09-20 12:48 ` [PATCH 5.4 CANDIDATE V2 11/17] xfs: always log corruption errors Chandan Babu R
2022-09-20 12:48 ` [PATCH 5.4 CANDIDATE V2 12/17] xfs: fix some memory leaks in log recovery Chandan Babu R
2022-09-20 12:48 ` Chandan Babu R [this message]
2022-09-20 12:48 ` [PATCH 5.4 CANDIDATE V2 14/17] xfs: use bitops interface for buf log item AIL flag check Chandan Babu R
2022-09-20 12:48 ` [PATCH 5.4 CANDIDATE V2 15/17] xfs: refactor agfl length computation function Chandan Babu R
2022-09-20 12:48 ` [PATCH 5.4 CANDIDATE V2 16/17] xfs: split the sunit parameter update into two parts Chandan Babu R
2022-09-20 12:48 ` [PATCH 5.4 CANDIDATE V2 17/17] xfs: don't commit sunit/swidth updates to disk if that would cause repair failures Chandan Babu R
2022-09-21 0:38 ` [PATCH 5.4 CANDIDATE V2 00/17] xfs stable candidate patches for 5.4.y (from v5.5) Darrick J. Wong
2022-09-21 2:13 ` Chandan Babu R
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=20220920124836.1914918-14-chandan.babu@oracle.com \
--to=chandan.babu@oracle.com \
--cc=amir73il@gmail.com \
--cc=djwong@kernel.org \
--cc=leah.rumancik@gmail.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