From: Carlos Maiolino <cem@kernel.org>
To: Lin Jiapeng <ljp1205831794@gmail.com>
Cc: linux-xfs@vger.kernel.org, stable@vger.kernel.org,
djwong@kernel.org, hch@lst.de, jiapenglin@tencent.com
Subject: Re: [PATCH v3] xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN
Date: Mon, 31 Aug 2026 10:03:23 +0200 [thread overview]
Message-ID: <apU1D-A8jtdYAcq6@andromeda.toxiclabs.cc> (raw)
In-Reply-To: <20260728071921.81156-1-jiapenglin@tencent.com>
On Tue, Jul 28, 2026 at 03:19:10PM +0800, Lin Jiapeng wrote:
> When exchanging two full-file ranges, xmi_can_exchange_reflink_flags()
> can move the reflink inode flag from the file that currently has it to
> the other file, as long as exactly one side is marked. This assumes
> that the file contents, and therefore all shared extents, are exchanged.
>
> That assumption is not true when XFS_EXCHMAPS_INO1_WRITTEN is set.
> xfs_exchmaps_can_skip_mapping() can skip hole and unwritten mappings
> from file1, so an exchange can complete without moving every mapping
> that the earlier flag-swap decision accounted for. In that case the
> post-operation cleanup can clear the reflink flag from an inode that
> still owns shared written extents. Later writes then take the
> non-reflink write path and may update blocks that should still have
> been protected by CoW, which shows up as data corruption between
> reflink-related files.
>
> Fix this by disabling the reflink flag exchange whenever
> XFS_EXCHMAPS_INO1_WRITTEN is requested. The contents exchange can still
> proceed; the conservative outcome is that both inodes keep the reflink
> flag. The regular reflink flag cleanup path can drop the extra flag
> later once the inode no longer has shared extents.
>
> Reported-by: Lin Jiapeng(TencentOS Red Team) <jiapenglin@tencent.com>
> Fixes: 966ceafc7a43 ("xfs: create deferred log items for file mapping exchanges")
> Cc: <stable@vger.kernel.org> # v6.10
> Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
> Signed-off-by: Lin Jiapeng <jiapenglin@tencent.com>
You don't need to send new versions just to add RwBs to the patch, we
can retrieve them from the list.
Also for any new versions, please add a changelog so we can easily
understand why the new version.
> ---
> fs/xfs/libxfs/xfs_exchmaps.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/fs/xfs/libxfs/xfs_exchmaps.c b/fs/xfs/libxfs/xfs_exchmaps.c
> index dcd0bd0b13b4..3efed37cb98a 100644
> --- a/fs/xfs/libxfs/xfs_exchmaps.c
> +++ b/fs/xfs/libxfs/xfs_exchmaps.c
> @@ -959,6 +959,16 @@ xmi_can_exchange_reflink_flags(
> {
> struct xfs_mount *mp = req->ip1->i_mount;
>
> + /*
> + * The INO1_WRITTEN optimization can skip exchanging hole and
> + * unwritten mappings, which means we cannot guarantee that all
> + * shared extents actually moved to the other file. Clearing the
> + * reflink flag of an inode that still holds shared extents breaks
> + * the CoW write path, so refuse to exchange the flags in that case.
> + */
> + if (req->flags & XFS_EXCHMAPS_INO1_WRITTEN)
> + return false;
> +
> if (hweight32(reflink_state) != 1)
> return false;
> if (req->startoff1 != 0 || req->startoff2 != 0)
> --
> 2.50.1 (Apple Git-155)
>
>
next prev parent reply other threads:[~2026-08-31 8:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 7:19 [PATCH v3] xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN Lin Jiapeng
2026-08-03 13:22 ` Carlos Maiolino
2026-08-31 8:03 ` Carlos Maiolino [this message]
2026-09-03 6:05 ` Carlos Maiolino
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=apU1D-A8jtdYAcq6@andromeda.toxiclabs.cc \
--to=cem@kernel.org \
--cc=djwong@kernel.org \
--cc=hch@lst.de \
--cc=jiapenglin@tencent.com \
--cc=linux-xfs@vger.kernel.org \
--cc=ljp1205831794@gmail.com \
--cc=stable@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