From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Chenyuan Yang <chenyuan0y@gmail.com>,
linux-btrfs@vger.kernel.org, clm@fb.com, josef@toxicpanda.com,
dsterba@suse.com
Cc: linux-kernel@vger.kernel.org, syzkaller@googlegroups.com,
Zijie Zhao <zzjas98@gmail.com>
Subject: Re: [Linux Kernel Bug] kernel BUG in btrfs_get_root_ref (assertion failed: !anon_dev) and general protection fault in btrfs_update_reloc_root
Date: Sat, 20 Jan 2024 16:29:44 +1030 [thread overview]
Message-ID: <fbe2009b-1ae8-4ebb-98e6-7ca9c2ef6584@gmx.com> (raw)
In-Reply-To: <CALGdzuo6awWdau3X=8XK547x2vX_-VoFmH1aPsqosRTQ5WzJVA@mail.gmail.com>
On 2024/1/20 14:45, Chenyuan Yang wrote:
> Dear Linux Kernel Developers for BTRFS,
>
> We encountered "kernel BUG in btrfs_get_root_ref" and "general
> protection fault in btrfs_update_reloc_root" when testing BTRFS with
> Syzkaller and our generated specifications.
>
> For "kernel BUG in btrfs_get_root_ref", it is an internal assertion
> failure `ASSERT(!anon_dev)` in `btrfs_get_root_ref`
> (https://elixir.bootlin.com/linux/latest/source/fs/btrfs/disk-io.c#L1319),
> which asserts the `anno_dev` should be NULL but it is preallocated
> here. I've attached the reproducible C program and report.
Thanks for this report, unfortunately the C reproducer did nothing
related to btrfs, it doesn't even try to mount any btrfs (no dmesg on
mounting/unmounting a btrfs at all).
I guess I'm missing something?
And through the dmesg, it looks like there is something weird here.
Firstly the ASSERT() got triggered means we didn't get any anon_dev
number assigned, but create_subvol() would return an error if its
get_anon_bdev() call failed.
So the only explanation I can come up with is, in a special system that
there is no anon_dev allocated at all, get_anon_bdev() can get @anon_dev
assigned to 0.
In that case, it just means the ASSERT() is not correct as it doesn't
take this case into consideration at all.
I can definitely submit a patch to remove the ASSERT().
Do you have any dedicated URL for this btrfs_get_root_ref() failure that
you want to put as "Reported-by" tag? Or I should just use your gmail
address as "Reported-by"?
Thanks,
Qu
>
> For "general protection fault in btrfs_update_reloc_root", it attempts
> to deference the null pointer in `refcount_inc_not_zero(&root->refs)`
> (https://elixir.bootlin.com/linux/latest/source/fs/btrfs/disk-io.h#L101),
> which is invoked by `btrfs_update_reloc_root`
> (https://elixir.bootlin.com/linux/v6.7/source/fs/btrfs/relocation.c#L926).
> Here is the call trace:
> ```
> general protection fault, probably for non-canonical address
> 0xdffffc00000000cd: 0000 [#1] PREEMPT SMP KASAN
> KASAN: null-ptr-deref in range [0x0000000000000668-0x000000000000066f]
> [ 1904.856783][T69219] Call Trace:
> [ 1904.857057][T69219] <TASK>
> [1904.857312][T69219] ? show_regs (arch/x86/kernel/dumpstack.c:479)
> [1904.857693][T69219] ? die_addr (arch/x86/kernel/dumpstack.c:421
> arch/x86/kernel/dumpstack.c:460)
> [1904.858074][T69219] ? exc_general_protection
> (arch/x86/kernel/traps.c:700 arch/x86/kernel/traps.c:642)
> [1904.858515][T69219] ? asm_exc_general_protection
> (./arch/x86/include/asm/idtentry.h:564)
> [1904.858941][T69219] ? btrfs_update_reloc_root
> (./include/linux/refcount.h:162 ./include/linux/refcount.h:227
> ./include/linux/refcount.h:245 fs/btrfs/disk-io.h:101
> fs/btrfs/relocation.c:926)
> [1904.859402][T69219] ? btrfs_update_reloc_root (fs/btrfs/relocation.c:929)
> ```
> Unfortunately, we failed to find the reproducible program for
> "general protection fault in btrfs_update_reloc_root". I have attached
> the report and log for it.
>
> If you have any questions or require more information, please feel
> free to contact us.
>
> Best,
> Chenyuan
next prev parent reply other threads:[~2024-01-20 6:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-20 4:15 [Linux Kernel Bug] kernel BUG in btrfs_get_root_ref (assertion failed: !anon_dev) and general protection fault in btrfs_update_reloc_root Chenyuan Yang
2024-01-20 5:59 ` Qu Wenruo [this message]
2024-01-20 6:25 ` Chenyuan Yang
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=fbe2009b-1ae8-4ebb-98e6-7ca9c2ef6584@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=chenyuan0y@gmail.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=josef@toxicpanda.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=syzkaller@googlegroups.com \
--cc=zzjas98@gmail.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 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.