From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org, fstests@vger.kernel.org
Subject: [PATCH] btrfs: add a test case to check btrfs won't crash on certain corruption
Date: Sat, 25 Feb 2023 17:14:38 +0800 [thread overview]
Message-ID: <20230225091438.55728-1-wqu@suse.com> (raw)
There seems to be a newly introduced regression that btrfs no longer
properly handles critical errors during mount.
Such regression lead to crash when mounting an fs with a corrupted tree
root.
The test case would reproduce the situation by creating an empty fs,
with SINGLE metadata profile, then corrupt the tree root manually.
Finally try mounting the corrupted fs, the mount should fail while our
kernel should not fail.
Signed-off-by: Qu Wenruo <wqu@suse.com>
---
The fix is titled "btrfs: fix the mount crash caused by confusing return
value", and is already submitted to the btrfs list.
Unfortunately git blame doesn't give a good enough clue on which commit
introduced the regression.
---
tests/btrfs/288 | 37 +++++++++++++++++++++++++++++++++++++
tests/btrfs/288.out | 2 ++
2 files changed, 39 insertions(+)
create mode 100755 tests/btrfs/288
create mode 100644 tests/btrfs/288.out
diff --git a/tests/btrfs/288 b/tests/btrfs/288
new file mode 100755
index 00000000..029603c8
--- /dev/null
+++ b/tests/btrfs/288
@@ -0,0 +1,37 @@
+#! /bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# Copyright (C) 2023 SUSE Linux Products GmbH. All Rights Reserved.
+#
+# FS QA Test 288
+#
+# Make sure btrfs handles critical errors gracefully during mount.
+#
+. ./common/preamble
+_begin_fstest auto quick dangerous
+
+. ./common/filter
+_supported_fs btrfs
+_require_scratch
+
+# Use single metadata profile so we only need to corrupt one copy of tree block
+_scratch_mkfs -m single > $seqres.full
+
+logical_root=$($BTRFS_UTIL_PROG inspect dump-tree -t root "$SCRATCH_DEV" | grep leaf | head -n1 | cut -f2 -d\ )
+physical_root=$(_btrfs_get_physical $logical_root 1)
+
+echo "tree root logical=$logical_root" >> $seqres.full
+echo "tree root physical=$physical_root" >> $seqres.full
+
+_pwrite_byte 0x00 "$physical_root" 4 $SCRATCH_DEV > $seqres.full
+
+# For unpatched kernel, the mount may lead to crash
+_try_scratch_mount >> $seqres.full 2>&1
+
+echo "Silence is golden"
+
+# Re-create the fs to avoid false alert from the corrupted fs.
+_scratch_mkfs -m single > $seqres.full
+
+# success, all done
+status=0
+exit
diff --git a/tests/btrfs/288.out b/tests/btrfs/288.out
new file mode 100644
index 00000000..2958a5c3
--- /dev/null
+++ b/tests/btrfs/288.out
@@ -0,0 +1,2 @@
+QA output created by 288
+Silence is golden
--
2.39.0
next reply other threads:[~2023-02-25 9:15 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-25 9:14 Qu Wenruo [this message]
2023-05-09 11:28 ` [PATCH] btrfs: add a test case to check btrfs won't crash on certain corruption Anand Jain
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=20230225091438.55728-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