Re: [PATCH] btrfs: Added null check to extent_root variable

From: Qu Wenruo
Date: Wed Sep 04 2024 - 17:31:52 EST




在 2024/9/5 03:16, David Sterba 写道:
On Wed, Sep 04, 2024 at 03:21:34PM +0930, Qu Wenruo wrote:


在 2024/9/4 12:07, Ghanshyam Agrawal 写道:
Reported-by: syzbot+9c3e0cdfbfe351b0bc0e@xxxxxxxxxxxxxxxxxxxxxxxxx
Closes:https://syzkaller.appspot.com/bug?extid=9c3e0cdfbfe351b0bc0e
Signed-off-by: Ghanshyam Agrawal <ghanshyam1898@xxxxxxxxx>
---
fs/btrfs/ref-verify.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/fs/btrfs/ref-verify.c b/fs/btrfs/ref-verify.c
index 9522a8b79d22..4e98ddf5e8df 100644
--- a/fs/btrfs/ref-verify.c
+++ b/fs/btrfs/ref-verify.c
@@ -1002,6 +1002,9 @@ int btrfs_build_ref_tree(struct btrfs_fs_info *fs_info)
return -ENOMEM;

extent_root = btrfs_extent_root(fs_info, 0);
+ if (!extent_root)
+ return -EIO;
+

Can you reproduce the original bug and are sure it's an NULL extent tree
causing the problem?

At least a quick glance into the console output shows there is no
special handling like rescue=ibadroots to ignore extent root, nor any
obvious corruption in the extent tree.

If extent root is really empty, we should error out way earlier.

Mind to explain the crash with more details?

In the stack trace it looks the ref-verify mount option is enabled, I
don't think we've tested that in combination with the rescue options as
ref-verify is a debugging tool, must be built in config (by default is
not and is not on distro configs).


Indeed it is the rescue=ibadroots mount option.
And unlike the regular mount options which all show a message line, none
of the rescue mount options will output an error message.

Thus that's why we're ignoring the missing extent root in
btrfs_read_block_groups().

In that case, yes the fix is correct.

Just need a small description on the combination to trigger the bug:

- Corrupted extent tree root

- rescue=ibadroots mount option

- Built-in ref-verify

Thanks,
Qu

We should fix the bug where it crashes when run in syzkaller so we can
allow it to continue coverage but otherwise I wouldn't put too much
effort into that. I.e. if we can do a simple fallback and exit gracefully
and not try to continue ref-verify + missint extent (or other trees).