Linux XFS filesystem development
 help / color / mirror / Atom feed
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)
> 
> 

  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