Re: Golden output mismatch from generic/228, fs independent

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

在 2025/9/3 07:10, Qu Wenruo 写道:
> 
> 
> 在 2025/9/2 21:39, Theodore Ts'o 写道:
>> On Tue, Sep 02, 2025 at 08:00:32PM +0930, Qu Wenruo wrote:
>>> Hi,
>>>
>>> Recently I updated my arm64 VM, and now several test cases are 
>>> failing due
>>> to golden output mismatch.
>>>
>>> This time it's fs independent, and I haven't yet updated fstests 
>>> itself, so
>>> it looks like some updates in my environment is breaking the test.
>>>
>>> E.g, generic/228 on ext4 (the same on btrfs)
>>>
>>> I checked my log, bash/xfsprogs and a lot of other packages are all 
>>> updated,
>>> and unfortunately my distro doesn't provide older packages for me to
>>> bisect...
>>
>> I don't know if this helps, but here's a kvm-xfstests using Debian
>> Trixie and certain updated critical packages (fio, quota, xfsprogs,
>> util-linux, etc.) overriden.  How does that differ from your distro
>> package versions?
>>
>> I haven't updated my arm64 image in a bit (this was from dated July 
>> 20th).
>> I can try doing an arm64 rebuild and see if a newer version still
>> works on arm64, but here's a data point....
>>
>>                         - TEd
>>
>>
>> KERNEL:    kernel       6.17.0-rc3-xfstests #1 SMP Tue Sep  2 07:57:28 
>> EDT 2025 aarch64
>> CMDLINE:   --arm64 -c ext4/4k generic/228
>> CPUS:      2
>> MEM:       1977.09
>>
>> ext4/4k: 1 tests, 5 seconds
>>    generic/228  Pass     2s
>> Totals: 1 tests, 0 skipped, 0 failures, 0 errors, 2s
>>
>> FSTESTVER: blktests     401420a (Fri, 6 Jun 2025 22:12:43 +0900)
>> FSTESTVER: fio          fio-3.40 (Tue, 20 May 2025 12:23:01 -0600)
> 
> Fio is in fact newer than mine. Mine is 3.39.
> 
>> FSTESTVER: fsverity     v1.6-2-gee7d74d (Mon, 17 Feb 2025 11:41:58 -0800)
>> FSTESTVER: ima-evm-utils        v1.5 (Mon, 6 Mar 2023 07:40:07 -0500)
>> FSTESTVER: libaio       libaio-0.3.108-82-gb8eadc9 (Thu, 2 Jun 2022 
>> 13:33:11 +0200)
> 
> Mine is a little newer, 0.3.113.
> 
>> FSTESTVER: ltp          20250130-280-g60656cbbb (Wed, 28 May 2025 
>> 15:04:44 +0200)
>> FSTESTVER: quota                v4.05-71-g4cd93fc (Sun, 27 Apr 2025 
>> 08:24:24 -0400)
>> FSTESTVER: util-linux   v2.41-40-g22b91501d (Mon, 26 May 2025 11:27:31 
>> +0200)
>> FSTESTVER: xfsprogs     v6.15.0 (Mon, 23 Jun 2025 13:56:41 +0200)
>> FSTESTVER: xfstests     v2025.07.13-12-gef63d1368 (Sat, 19 Jul 2025 
>> 18:14:29 -0400)
>> FSTESTVER: xfstests-bld gce-xfstests-202504292206-20-g905451c1 (Sun, 
>> 20 Jul 2025 03:04:27 +0000)
>> FSTESTVER: zz_build-distro      trixie
> 
> Others are mostly the same version.
> 
> 
> And indeed it's bash, after rolling back to v5.2.037 bash, everything is 
> fine.
> 
> It looks like it's bash 5.3.x starting to fail (5.3.0 tested and failed).
> 
> I'll try dig a little deeper, and this is why I'm always running 
> Archlinux (ArchlinuxARM in this case), to give some early warnings of 
> some unexpected updates breaking the test cases.

It turns out to be the core dump behavior, the following script can 
easily reproduce it:

```
#!/bin/bash

dev="/dev/test/scratch1"
mnt="/mnt/btrfs"

mkfs.btrfs -f $dev > /dev/null
mount $dev $mnt
sysctl -w kernel.core_pattern=core &>/dev/null
ulimit -c 0
ulimit -f 102400
xfs_io -f -c "falloc 0 101m" /mnt/btrfs/foobar
umount $mnt
```

Xfs_io will trigger coredump, and the full cmdline dump belongs to the 
core dump handling of bash.

Thanks,
Qu


> 
> Thanks,
> Qu
> 
>> FSTESTCFG: ext4/4k
>> FSTESTSET: generic/228
>> FSTESTOPT: aex
>> Truncating test artifacts in /results to 31k
>>
>