FS/XFS testing framework
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Zorro Lang <zlang@redhat.com>
Cc: fstests <fstests@vger.kernel.org>, xfs <linux-xfs@vger.kernel.org>
Subject: [PATCH] xfs/444: fix agfl reset warning detection for small log buffers
Date: Wed, 3 Jul 2024 14:36:05 -0700	[thread overview]
Message-ID: <20240703213605.GK103020@frogsfrogsfrogs> (raw)

From: Darrick J. Wong <djwong@kernel.org>

Collectively, the ten subtests in xfs/444 can generate a lot of kernel
log data.  If the amount of log data is enough to overflow the kernel
log buffers, the AGFL reset warning generated by fix_start and fix_wrap
might have been overwritten by subsequent log data.  Fix this by
checking for the reset warning after each test and only complaining if
at the end if we have /never/ seen the warning.

Found by running on a kernel configured with CONFIG_LOG_BUF_SHIFT=14
(16K).  This happened to be a Raspberry Pi, but in principle this can
happen to anyone.  I'd never noticed this before because x86 helpfully
sets it to 17 (128K) by default.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
---
 tests/xfs/444 |   14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/tests/xfs/444 b/tests/xfs/444
index db7418c55d..cf78a9a1f0 100755
--- a/tests/xfs/444
+++ b/tests/xfs/444
@@ -58,6 +58,10 @@ dump_ag0() {
 	_scratch_xfs_db -c 'sb 0' -c 'p' -c 'agf 0' -c 'p' -c 'agfl 0' -c 'p'
 }
 
+# Did we get the kernel warning too?
+warn_str='WARNING: Reset corrupted AGFL'
+saw_agfl_reset_warning=0
+
 runtest() {
 	cmd="$1"
 
@@ -208,6 +212,8 @@ ENDL
 	echo "FS REMOUNT" >> $seqres.full
 	dump_ag0 > $tmp.remount 2> /dev/null
 	diff -u $tmp.repair $tmp.remount >> $seqres.full
+
+	_check_dmesg_for "${warn_str}" && ((saw_agfl_reset_warning++))
 }
 
 runtest fix_end
@@ -221,9 +227,11 @@ runtest bad_start
 runtest no_move
 runtest simple_move
 
-# Did we get the kernel warning too?
-warn_str='WARNING: Reset corrupted AGFL'
-_check_dmesg_for "${warn_str}" || echo "Missing dmesg string \"${warn_str}\"."
+# We must see the AGFL reset warning at least once.  Collectively, the subtests
+# can generate enough kernel log data to overflow the buffer, so we check for
+# the warning after each subtest and summarize the output here.
+((saw_agfl_reset_warning > 0)) || \
+	echo "Missing dmesg string \"${warn_str}\"."
 
 # Now run the regular dmesg check, filtering out the agfl warning
 filter_agfl_reset_printk() {

             reply	other threads:[~2024-07-03 21:36 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-03 21:36 Darrick J. Wong [this message]
2024-07-04  6:05 ` [PATCH] xfs/444: fix agfl reset warning detection for small log buffers Christoph Hellwig

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=20240703213605.GK103020@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=zlang@redhat.com \
    /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