[PATCH 0/2] Fix two issues about swapext

[PATCH 0/2] Fix two issues about swapext

[Ye Bin]

From: Ye Bin <yebin10@huawei.com>

Ye Bin (2):
  xfs: fix checksum error when call xfs_recover_inode_owner_change()
  xfs: fix xfs_recover_inode_owner_change() failed

 fs/xfs/xfs_inode_item.c         | 4 ++--
 fs/xfs/xfs_inode_item_recover.c | 9 +++++++--
 2 files changed, 9 insertions(+), 4 deletions(-)

-- 
2.34.1

[PATCH 1/2] xfs: fix checksum error when call xfs_recover_inode_owner_change()

[Ye Bin]

From: Ye Bin <yebin10@huawei.com>

There's a issue as follows:
XFS (sda): Metadata corruption detected at xfs_dinode_verify+0x621/0x25e0,
XFS (sda): Unmount and run xfs_repair
XFS (sda): First 128 bytes of corrupted metadata buffer:
00000000: 49 4e 81 a4 03 02 00 00 00 00 00 00 00 00 00 00  IN..............
00000010: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000020: 69 3c b0 4e 29 aa 08 0b 69 3c b0 52 01 d9 29 a7  i<.N)...i<.R..).
00000030: 69 3c b0 52 01 d9 29 a7 00 00 00 00 00 01 e0 00  i<.R..).........
00000040: 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 0f  ................
00000050: 00 00 00 02 00 00 00 00 00 00 00 02 fb d9 c8 fa  ................
00000060: ff ff ff ff bc 93 09 78 00 00 00 00 00 00 00 f7  .......x........
00000070: 00 00 00 01 00 00 00 49 00 00 00 00 00 00 00 00  .......I........
XFS (sda): Filesystem has been shut down due to log error (0x2).
XFS (sda): Please unmount the filesystem and rectify the problem(s).
XFS (sda): log mount/recovery failed: error -117
XFS (sda): log mount failed

Above issue happens as miss re-generate the inode checksum before call
xfs_recover_inode_owner_change(). As xfs_inode_from_disk() will call
xfs_dinode_verify() to verify inode.

Fixes: 2d6051d49653 ("xfs: call xfs_dinode_verify from xfs_inode_from_disk")
Signed-off-by: Ye Bin <yebin10@huawei.com>
---
 fs/xfs/xfs_inode_item_recover.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/fs/xfs/xfs_inode_item_recover.c b/fs/xfs/xfs_inode_item_recover.c
index 9d1999d41be1..d27f43d81127 100644
--- a/fs/xfs/xfs_inode_item_recover.c
+++ b/fs/xfs/xfs_inode_item_recover.c
@@ -566,13 +566,18 @@ xlog_recover_inode_commit_pass2(
 	}
 
 out_owner_change:
+	/*
+	 * re-generate the checksum before recover inode owner change as
+	 * xfs_inode_from_disk() will call xfs_dinode_verify().
+	 */
+	xfs_dinode_calc_crc(log->l_mp, dip);
+
 	/* Recover the swapext owner change unless inode has been deleted */
 	if ((in_f->ilf_fields & (XFS_ILOG_DOWNER|XFS_ILOG_AOWNER)) &&
 	    (dip->di_mode != 0))
 		error = xfs_recover_inode_owner_change(mp, dip, in_f,
 						       buffer_list);
-	/* re-generate the checksum and validate the recovered inode. */
-	xfs_dinode_calc_crc(log->l_mp, dip);
+	/* Validate the recovered inode */
 	fa = xfs_dinode_verify(log->l_mp, in_f->ilf_ino, dip);
 	if (fa) {
 		XFS_CORRUPTION_ERROR(
-- 
2.34.1

[PATCH 2/2] xfs: fix xfs_recover_inode_owner_change() failed

[Ye Bin]

From: Ye Bin <yebin10@huawei.com>

There's a issue as follows:
XFS: Assertion failed: in_f->ilf_fields & XFS_ILOG_DBROOT, file:
fs/xfs/xfs_inode_item_recover.c, line: 100
------------[ cut here ]------------
kernel BUG at fs/xfs/xfs_message.c:102!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 1 UID: 0 PID: 15687 Comm: mount Not tainted 6.18.0-next
RIP: 0010:assfail+0x9f/0xb0
RSP: 0018:ffffc90008de7340 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffffffff8380ffa6
RDX: ffff88811abdba80 RSI: ffffffff8380ffcf RDI: 0000000000000001
RBP: 0000000000000000 R08: 0000000000000001 R09: fffff520011bcdf9
R10: 0000000000000001 R11: 0000000000000001 R12: ffffffff8af4fc60
R13: 0000000000000064 R14: ffffc90008de7860 R15: 0000000000000000
FS:  00007f0950a07880(0000) GS:ffff88878ad5b000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f144fa03000 CR3: 00000001133b4000 CR4: 00000000000006f0
Call Trace:
 <TASK>
 xfs_recover_inode_owner_change+0x346/0x3a0
 xlog_recover_inode_commit_pass2+0x150e/0x2820
 xlog_recover_items_pass2+0x102/0x170
 xlog_recover_commit_trans+0x43f/0x980
 xlog_recovery_process_trans+0x1c0/0x1e0
 xlog_recover_process_ophdr+0x1ef/0x420
 xlog_recover_process_data+0x1ad/0x480
 xlog_recover_process+0x26d/0x480
 xlog_do_recovery_pass+0x6ea/0xfb0
 xlog_do_log_recovery+0xa7/0x110
 xlog_do_recover+0xe9/0x4e0
 xlog_recover+0x2af/0x500
 xfs_log_mount+0x23d/0x590
 xfs_mountfs+0x10b8/0x2260
 xfs_fs_fill_super+0x16aa/0x21d0
 get_tree_bdev_flags+0x38f/0x620
 vfs_get_tree+0x9c/0x380
 path_mount+0x72b/0x21c0
 __x64_sys_mount+0x298/0x310
 do_syscall_64+0x72/0xf80

Above issue happens as miss add XFS_ILOG_DOWNER flag for inode which format
is XFS_DINODE_FMT_EXTENTS.
We can reproduce above issue as follow steps:
1. Create two files with XFS_DINODE_FMT_BTREE format.
fallocate -l1m  /tmp/file1
for i in `seq 1 127`;do fallocate -p -o $((8192*i)) -l 4096 /tmp/file1;done
fallocate -l1m  /home/test/file2
for i in `seq 1 127`;do fallocate -p -o $((8192*i)) -l 4096 /tmp/file2;done
2. Swap two files with XFS_IOC_SWAPEXT IOCTL command.
3. Make inode with XFS_DINODE_FMT_EXTENTS format.
truncate -s 81920 /home/test/file1
truncate -s 81920 /home/test/file2
4. Wait for iclog submit to disk then power off.
5. Mount xfs file system will reproduce above issue.

To solve above issue there's need to clear XFS_ILOG_DOWNER flag for inode
which has XFS_DINODE_FMT_EXTENTS data format.

Fixes: 21b5c9784bce ("xfs: swap extents operations for CRC filesystems")
Signed-off-by: Ye Bin <yebin10@huawei.com>
---
 fs/xfs/xfs_inode_item.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/xfs/xfs_inode_item.c b/fs/xfs/xfs_inode_item.c
index 81dfe70e173d..f3ea98504cf0 100644
--- a/fs/xfs/xfs_inode_item.c
+++ b/fs/xfs/xfs_inode_item.c
@@ -343,8 +343,8 @@ xfs_inode_item_format_data_fork(
 
 	switch (ip->i_df.if_format) {
 	case XFS_DINODE_FMT_EXTENTS:
-		iip->ili_fields &=
-			~(XFS_ILOG_DDATA | XFS_ILOG_DBROOT | XFS_ILOG_DEV);
+		iip->ili_fields &= ~(XFS_ILOG_DDATA | XFS_ILOG_DBROOT |
+				     XFS_ILOG_DEV | XFS_ILOG_DOWNER);
 
 		if ((iip->ili_fields & XFS_ILOG_DEXT) &&
 		    ip->i_df.if_nextents > 0 &&
-- 
2.34.1

Re: [PATCH 0/2] Fix two issues about swapext

[Christoph Hellwig]

Can you add a sentence or two here how you found the issue?

Any chance you could add a reproducer to xfstests?

Re: [PATCH 0/2] Fix two issues about swapext

[yebin]

On 2025/12/15 13:37, Christoph Hellwig wrote:
> Can you add a sentence or two here how you found the issue?
>

First, we encountered the issue described in 
https://access.redhat.com/solutions/6095011 in our production 
environment.The triggered scenario is that after performing fragmented 
organization, the system suddenly lost power and reset, and then 
encountered a panic when mounting the XFS file system.
After analyzing the vmcore, we identified the cause of the issue. 
Subsequently, while reproducing the issue on linux-next, we also 
discovered the problem described in PATCH[1].

> Any chance you could add a reproducer to xfstests?
>
Yes, this issue is quite reproducible. It occurs inevitably when 
following certain steps. This problem has existed for a long time. I 
think the reason it's not easily detected is that the XFS_IOC_SWAPEXT 
IOCTL command is generally used during defragmentation. Therefore, it is 
almost never included in typical log replay scenarios.
>

Re: [PATCH 0/2] Fix two issues about swapext

[Christoph Hellwig]

On Mon, Dec 15, 2025 at 03:19:43PM +0800, yebin wrote:
> First, we encountered the issue described in
> https://access.redhat.com/solutions/6095011 in our production

That's behind a paywall unfortunately.

> > Any chance you could add a reproducer to xfstests?
> > 
> Yes, this issue is quite reproducible. It occurs inevitably when following
> certain steps. This problem has existed for a long time. I think the reason
> it's not easily detected is that the XFS_IOC_SWAPEXT IOCTL command is
> generally used during defragmentation. Therefore, it is almost never
> included in typical log replay scenarios.

Can you send out an xfstests for this?  Or at least a shell script
fragment?

Re: [PATCH 0/2] Fix two issues about swapext

[yebin]

On 2025/12/15 22:29, Christoph Hellwig wrote:
> On Mon, Dec 15, 2025 at 03:19:43PM +0800, yebin wrote:
>> First, we encountered the issue described in
>> https://access.redhat.com/solutions/6095011 in our production
>
> That's behind a paywall unfortunately.
>
In fact, the root cause of the problem was not identified.
>>> Any chance you could add a reproducer to xfstests?
>>>
>> Yes, this issue is quite reproducible. It occurs inevitably when following
>> certain steps. This problem has existed for a long time. I think the reason
>> it's not easily detected is that the XFS_IOC_SWAPEXT IOCTL command is
>> generally used during defragmentation. Therefore, it is almost never
>> included in typical log replay scenarios.
>
> Can you send out an xfstests for this?  Or at least a shell script
> fragment?
>
You can reproduce issue as follow steps:
mkfs.xfs -f /dev/sdb
mount  /dev/sdb /home/test
fallocate -l1m  /home/test/file1
for i in `seq 1 127`;do fallocate -p -o $((8192*i)) -l 4096 
/home/test/file1;done
fallocate -l1m  /home/test/file2
for i in `seq 1 127`;do fallocate -p -o $((8192*i)) -l 4096 
/home/test/file2;done
umount /home/test
mount /dev/sdb /home/test
xfs_io -c "swapext /home/test/file1" /home/test/file2
truncate -s 81920 /home/test/file1
truncate -s 81920 /home/test/file2
// wait for iclog submit to disk
echo offline > /sys/class/scsi_disk/0\:0\:0\:1/device/state && umount 
/home/test
echo running > /sys/class/scsi_disk/0\:0\:0\:1/device/state
mount /dev/sdb /home/test  //will trigger issue