FS/XFS testing framework
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org, fstests@vger.kernel.org
Subject: [PATCH v2] fstests: generic/228: do not rely on the bash core dump output
Date: Thu,  4 Sep 2025 15:49:44 +0930	[thread overview]
Message-ID: <20250904061944.105518-1-wqu@suse.com> (raw)

[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>
---
Changelog:
v2:
- Remove all coredump related code.
  As we ignored the signal, no coredump will be triggered.
---
 tests/generic/228     | 28 +++++++---------------------
 tests/generic/228.out |  2 +-
 2 files changed, 8 insertions(+), 22 deletions(-)

diff --git a/tests/generic/228 b/tests/generic/228
index f1881f84..d7bd9b7a 100755
--- a/tests/generic/228
+++ b/tests/generic/228
@@ -9,22 +9,6 @@
 . ./common/preamble
 _begin_fstest rw auto prealloc quick
 
-# Override the default cleanup function.
-_cleanup()
-{
-	cd /
-	rm -f $tmp.*
-	sysctl -w kernel.core_pattern="$core_pattern" &>/dev/null
-	ulimit -c $ulimit_c
-}
-
-tmp=$TEST_DIR/$$
-core_pattern=`sysctl -n kernel.core_pattern`
-ulimit_c=`ulimit -c`
-_register_cleanup "_cleanup" 25
-
-# Import common functions.
-
 # generic, but xfs_io's fallocate must work
 # only Linux supports fallocate
 _require_test
@@ -38,10 +22,6 @@ _require_xfs_io_command "falloc"
 avail=`df -P $TEST_DIR | awk 'END {print $4}'`
 [ "$avail" -ge 104000 ] || _notrun "Test device is too small ($avail KiB)"
 
-# Suppress core dumped messages
-sysctl -w kernel.core_pattern=core &>/dev/null
-ulimit -c 0
-
 # Set the FSIZE ulimit to 100MB and check
 ulimit -f 102400
 flim=`ulimit -f`
@@ -50,7 +30,13 @@ flim=`ulimit -f`
 
 echo "File size limit is now set to 100 MB."
 echo "Let us try to preallocate 101 MB. This should fail."
-$XFS_IO_PROG -f -c 'falloc 0 101m' $TEST_DIR/ouch
+# xfs_io will receive SIGXFSZ signal, if not handled it will trigger a coredump.
+#
+# And in bash 5.3.x, bash will always output the command/script triggering the
+# coredump.
+# Work around the new behavior by ignoring the signal.
+# Falloc will still fail but with a more reliable error message.
+bash -c "trap '' SIGXFSZ; $XFS_IO_PROG -f -c 'falloc 0 101m' $TEST_DIR/ouch"
 rm -f $TEST_DIR/ouch
 
 echo "Let us now try to preallocate 50 MB. This should succeed."
diff --git a/tests/generic/228.out b/tests/generic/228.out
index 842d4bb7..00d041f6 100644
--- a/tests/generic/228.out
+++ b/tests/generic/228.out
@@ -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
+fallocate: File too large
 Let us now try to preallocate 50 MB. This should succeed.
 Test over.
-- 
2.51.0


             reply	other threads:[~2025-09-04  6:20 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-04  6:19 Qu Wenruo [this message]
2025-09-04 13:00 ` [PATCH v2] fstests: generic/228: do not rely on the bash core dump output Theodore Ts'o

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=20250904061944.105518-1-wqu@suse.com \
    --to=wqu@suse.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@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