From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/3] btrfs: fix an ASSERT() triggered inside prepare_to_merge()
Date: Wed, 2 Aug 2023 18:02:18 +0800 [thread overview]
Message-ID: <cover.1690970028.git.wqu@suse.com> (raw)
[CHANGELOG]
v2:
- Add two new patches
One to properly fix the root cause (race between quota tree creation
and relocation).
One to reject obviously corrupted reloc trees.
- Remove two ASSERT()s from merge_reloc_roots()
[BUG]
Syzbot reported an ASSERT() triggered inside prepare_to_merge(), which
turns out to be a regression caused by commit 85724171b302 ("btrfs: fix
the btrfs_get_global_root return value").
[CAUSE]
The race can happen between quota tree creation and relocation, the root
cause is btrfs_get_fs_root() can try to read quota tree as one fs tree,
thus setting ROOT_SHAREABLE flag.
This leads to relocation code to create a new reloc tree for quota tree,
which should not happen.
Furthermore at later relocation stages, we will grab quota root from
fs_info->quota_root, which is not the same as the one read by
btrfs_get_fs_root(), thus quota_root->reloc_root is NULL.
This triggers the ASSERT() and crash the system.
[FIX]
- Make sure non-subvolume trees are always grabbed from fs_info
This changes btrfs_get_root_ref() to a more explicit checks,
and would return PTR_ERR(-ENOENT) if a non-subvolume (data reloc tree
still counts as a subvolume tree) objectid is provided.
This is the root fix.
- Replace the ASSERT() with a more graceful exit
Still does the extra kernel warning through
btrfs_abort_transaction(), but with more useful error messages.
- Reject obviously incorrect reloc trees through tree-checker
Just another layer of sanity checks for on-disk data.
Qu Wenruo (3):
btrfs: avoid race with qgroup tree creation and relocation
btrfs: exit gracefully if reloc roots don't match
btrfs: reject invalid reloc tree root keys with stack dump
fs/btrfs/disk-io.c | 13 ++++++++++++-
fs/btrfs/relocation.c | 40 ++++++++++++++++++++++++++++++++++------
fs/btrfs/tree-checker.c | 15 +++++++++++++++
3 files changed, 61 insertions(+), 7 deletions(-)
--
2.41.0
next reply other threads:[~2023-08-02 10:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-02 10:02 Qu Wenruo [this message]
2023-08-02 10:02 ` [PATCH v2 1/3] btrfs: avoid race with qgroup tree creation and relocation Qu Wenruo
2023-08-02 11:59 ` Filipe Manana
2023-08-02 10:02 ` [PATCH v2 2/3] btrfs: exit gracefully if reloc roots don't match Qu Wenruo
2023-08-02 12:05 ` Filipe Manana
2023-08-02 10:02 ` [PATCH v2 3/3] btrfs: reject invalid reloc tree root keys with stack dump Qu Wenruo
2023-08-02 12:11 ` Filipe Manana
2023-08-02 21:32 ` Qu Wenruo
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=cover.1690970028.git.wqu@suse.com \
--to=wqu@suse.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.