Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 29E2F37A498; Thu, 20 Aug 2026 15:09:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787238546; cv=none; b=cBxOiFLlkoxv4SweCOCnWqdF5vhx01RLKgSOfU8+CXhgpMJ72IHedYy0UGtINmoxo37P0bV544AgZovNiGI8iywJjd6CV2QnANdumou1BV/Y8+GTuDnS1Wd1UYGs2mKFFsxBORY8U3MB6ZO6Jz1F9peePUY7/1sXOS2RfftNN8k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787238546; c=relaxed/simple; bh=ds0NQ0n81Eve3gGP8LF99P4INLbT5Vu6mSuhSMl4Ua0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dFmzyo8kGEj2O9+skQuaNEtYmJ9ebhwuk0+0570LzubYtBtq/tGWKxOFvEuhoDpCI1oWz1vqWyX4FIUbRVLflM8qsNEi+/tha7tT8V4GRabrQhMfoasEFcOjpjOfpRBY6Ntj1y4dimhCNXVfmU8UkAC7FAhjh1AkM/aorq24aGI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=qOi/V0bb; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="qOi/V0bb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C87B1F000E9; Thu, 20 Aug 2026 15:09:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1787238544; bh=B0Hb8MbIPGwYcftVllSWtWzqYxzhuGQSZJWHWvboE4M=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=qOi/V0bbg+9G2/p+WifStD6086Em9BbMBapMoCwkHsmt2ahXB2km7YvXmae4e+4FE wZmngFjrxCzu+j11RyaMvvVpcpnyE6Am97jERoApbkNeODcS896cd1OI/qjNamfG5Y ZWWkrI7FXCfvH0tpohd40nyqIeBAtICPbrQ6GFcE= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, "Lin Jiapeng (TencentOS Red Team)" , "Darrick J. Wong" , Christoph Hellwig , Carlos Maiolino Subject: [PATCH 7.1 146/228] xfs: fix exchange-range reflink flag clearing issue with INO1_WRITTEN Date: Thu, 20 Aug 2026 16:54:48 +0200 Message-ID: <20260820145249.052416488@linuxfoundation.org> X-Mailer: git-send-email 2.55.0 In-Reply-To: <20260820145244.450574346@linuxfoundation.org> References: <20260820145244.450574346@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 7.1-stable review patch. If anyone has any objections, please let me know. ------------------ From: Lin Jiapeng commit b2d5a81dae385333f9734910277fbf94c78bd17f upstream. 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) Fixes: 966ceafc7a43 ("xfs: create deferred log items for file mapping exchanges") Cc: stable@vger.kernel.org # v6.10 Reviewed-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Lin Jiapeng Signed-off-by: Carlos Maiolino Signed-off-by: Greg Kroah-Hartman --- fs/xfs/libxfs/xfs_exchmaps.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- 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)