From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: Ghanshyam Agrawal <ghanshyam1898@gmail.com>,
clm@fb.com, josef@toxicpanda.com, dsterba@suse.com,
linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org,
syzbot+9c3e0cdfbfe351b0bc0e@syzkaller.appspotmail.com
Subject: Re: [PATCH] btrfs: Added null check to extent_root variable
Date: Wed, 4 Sep 2024 19:46:30 +0200 [thread overview]
Message-ID: <20240904174630.GP26776@twin.jikos.cz> (raw)
In-Reply-To: <9ee34826-259f-45a1-99d5-a21262489e49@gmx.com>
On Wed, Sep 04, 2024 at 03:21:34PM +0930, Qu Wenruo wrote:
>
>
> 在 2024/9/4 12:07, Ghanshyam Agrawal 写道:
> > Reported-by: syzbot+9c3e0cdfbfe351b0bc0e@syzkaller.appspotmail.com
> > Closes:https://syzkaller.appspot.com/bug?extid=9c3e0cdfbfe351b0bc0e
> > Signed-off-by: Ghanshyam Agrawal <ghanshyam1898@gmail.com>
> > ---
> > 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).
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).
next prev parent reply other threads:[~2024-09-04 17:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-04 2:37 [PATCH] btrfs: Added null check to extent_root variable Ghanshyam Agrawal
2024-09-04 5:51 ` Qu Wenruo
2024-09-04 15:50 ` Ghanshyam Agrawal
2024-09-04 21:25 ` Qu Wenruo
2024-09-04 17:46 ` David Sterba [this message]
2024-09-04 21:31 ` 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=20240904174630.GP26776@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=ghanshyam1898@gmail.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.com \
--cc=syzbot+9c3e0cdfbfe351b0bc0e@syzkaller.appspotmail.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