fstests: generic/228: do not rely on the bash core dump output
[BUG]
With bash 5.3.x, the test case generic/228 will always fail with the
following golden output mismatch:
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 btrfs-vm 6.17.0-rc3-custom+ #281 SMP PREEMPT_DYNAMIC Thu Aug 28 11:15:21 ACST 2025
MKFS_OPTIONS -- /dev/mapper/test-scratch1
MOUNT_OPTIONS -- /dev/mapper/test-scratch1 /mnt/scratch
generic/228 1s ... - output mismatch (see /home/adam/xfstests/results//generic/228.out.bad)
--- tests/generic/228.out 2025-09-04 15:15:08.
965000000 +0930
+++ /home/adam/xfstests/results//generic/228.out.bad 2025-09-04 15:16:05.
627457599 +0930
@@ -1,6 +1,6 @@
QA output created by 228
File size limit is now set to 100 MB.
Let us try to preallocate 101 MB. This should fail.
-File size limit exceeded
+File size limit exceeded $XFS_IO_PROG -f -c 'falloc 0 101m' $TEST_DIR/ouch
Let us now try to preallocate 50 MB. This should succeed.
Test over.
...
(Run 'diff -u /home/adam/xfstests/tests/generic/228.out /home/adam/xfstests/results//generic/228.out.bad' to see the entire diff)
Ran: generic/228
Failures: generic/228
Failed 1 of 1 tests
[CAUSE]
The "File size limit exceeded" line is never from xfs_io, but the
coredump from bash itself.
And with latest 5.3.x bash, it added extra dump during such core dump
handling (even if we have explicitly skipped the coredump).
[FIX]
Instead of relying on bash to do the coredump, which is unreliable
between different bash versions as I have shown above, ignore the
SIGXFSZ signal so that xfs_io will do the error output, which is more
reliable than bash.
And since we do not need to bother the coredump behavior, remove all the
cleanup and preparation for coredump.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Zorro Lang <zlang@kernel.org>