Hi Qu,

Thanks very much for your prompt reply!

>> it doesn't even try to mount any btrfs (no dmesg on
>> mounting/unmounting a btrfs at all).
>> I guess I'm missing something?

I just attached the mounted `mount_0.gz` in the repro in this email.
In the `btrfs_get_root_ref-repro.prog`, it seems that the Syzkaller
program mounts the btrfs in the beginning.
Sorry that I am not familiar with the mounting of the btrfs system.

>> 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"?

Thank you for highlighting this. Kindly use my Gmail address for the
'Reported-by' tag.

Best,
Chenyuan

On Fri, Jan 19, 2024 at 11:59 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>
>
> 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