Hello,
syzbot found the following issue on:
HEAD commit: 1434a312 Merge branch 'for-5.13-fixes' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=162843f3d00000
kernel config: https://syzkaller.appspot.com/x/.config?x=9f3da44a01882e99
dashboard link: https://syzkaller.appspot.com/bug?extid=a6bf271c02e4fe66b4e4
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]
assertion failed: !memcmp(fs_info->fs_devices->fsid, fs_info->super_copy->fsid, BTRFS_FSID_SIZE), in fs/btrfs/disk-io.c:3282
------------[ cut here ]------------
kernel BUG at fs/btrfs/ctree.h:3419!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 23125 Comm: syz-executor.5 Not tainted 5.13.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:assertfail.constprop.0+0x27/0x29 fs/btrfs/ctree.h:3419
Code: 3c 54 fa 41 54 41 89 f4 55 48 89 fd e8 d5 90 94 f8 44 89 e1 48 89 ee 48 c7 c2 00 92 b1 89 48 c7 c7 40 92 b1 89 e8 ab 1f f6 ff <0f> 0b 41 56 41 55 41 54 55 53 48 89 fb e8 aa 90 94 f8 48 8d 7b 48
RSP: 0018:ffffc9000e8b7848 EFLAGS: 00010286
RAX: 000000000000007c RBX: 0000000000000027 RCX: 0000000000000000
RDX: 0000000000040000 RSI: ffffffff815c1445 RDI: fffff52001d16efb
RBP: ffffffff89b1bf40 R08: 000000000000007c R09: 0000000000000000
R10: ffffffff815bb27e R11: 0000000000000000 R12: 0000000000000cd2
R13: ffff888035849000 R14: 0000000000000001 R15: ffff88803b8e0000
FS: 00007fde076e9700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000568000 CR3: 000000008c97f000 CR4: 00000000001506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
open_ctree+0xdae/0x411f fs/btrfs/disk-io.c:3282
btrfs_fill_super fs/btrfs/super.c:1382 [inline]
btrfs_mount_root.cold+0x14/0x165 fs/btrfs/super.c:1749
legacy_get_tree+0x105/0x220 fs/fs_context.c:592
vfs_get_tree+0x89/0x2f0 fs/super.c:1498
fc_mount fs/namespace.c:993 [inline]
vfs_kern_mount.part.0+0xd3/0x170 fs/namespace.c:1023
vfs_kern_mount+0x3c/0x60 fs/namespace.c:1010
btrfs_mount+0x234/0xa20 fs/btrfs/super.c:1809
legacy_get_tree+0x105/0x220 fs/fs_context.c:592
vfs_get_tree+0x89/0x2f0 fs/super.c:1498
do_new_mount fs/namespace.c:2905 [inline]
path_mount+0x132a/0x1fa0 fs/namespace.c:3235
do_mount fs/namespace.c:3248 [inline]
__do_sys_mount fs/namespace.c:3456 [inline]
__se_sys_mount fs/namespace.c:3433 [inline]
__x64_sys_mount+0x27f/0x300 fs/namespace.c:3433
do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x467afa
Code: 48 c7 c2 bc ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d2 e8 b8 04 00 00 0f 1f 84 00 00 00 00 00 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fde076e8fa8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 0000000020000200 RCX: 0000000000467afa
RDX: 0000000020000000 RSI: 0000000020000100 RDI: 00007fde076e9000
RBP: 00007fde076e9040 R08: 00007fde076e9040 R09: 0000000020000000
R10: 0000000000000000 R11: 0000000000000202 R12: 0000000020000000
R13: 0000000020000100 R14: 00007fde076e9000 R15: 0000000020000040
Modules linked in:
---[ end trace 5e4a13f31c27e3bb ]---
RIP: 0010:assertfail.constprop.0+0x27/0x29 fs/btrfs/ctree.h:3419
Code: 3c 54 fa 41 54 41 89 f4 55 48 89 fd e8 d5 90 94 f8 44 89 e1 48 89 ee 48 c7 c2 00 92 b1 89 48 c7 c7 40 92 b1 89 e8 ab 1f f6 ff <0f> 0b 41 56 41 55 41 54 55 53 48 89 fb e8 aa 90 94 f8 48 8d 7b 48
RSP: 0018:ffffc9000e8b7848 EFLAGS: 00010286
RAX: 000000000000007c RBX: 0000000000000027 RCX: 0000000000000000
RDX: 0000000000040000 RSI: ffffffff815c1445 RDI: fffff52001d16efb
RBP: ffffffff89b1bf40 R08: 000000000000007c R09: 0000000000000000
R10: ffffffff815bb27e R11: 0000000000000000 R12: 0000000000000cd2
R13: ffff888035849000 R14: 0000000000000001 R15: ffff88803b8e0000
FS: 00007fde076e9700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fb2751c7000 CR3: 000000008c97f000 CR4: 00000000001506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at [email protected].
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
On 31.05.21 г. 10:53, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 1434a312 Merge branch 'for-5.13-fixes' of git://git.kernel..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=162843f3d00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=9f3da44a01882e99
> dashboard link: https://syzkaller.appspot.com/bug?extid=a6bf271c02e4fe66b4e4
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: [email protected]
>
> assertion failed: !memcmp(fs_info->fs_devices->fsid, fs_info->super_copy->fsid, BTRFS_FSID_SIZE), in fs/btrfs/disk-io.c:3282
This means a device contains a btrfs filesystem which has a different
FSID in its superblock than the fsid which all devices part of the same
fs_devices should have. This can happen in 2 ways - memory corruption
where either of the ->fsid member are corrupted or if there was a crash
while a filesystem's fsid was being changed. We need more context about
what the test did?
On Mon, May 31, 2021 at 10:44 AM 'Nikolay Borisov' via syzkaller-bugs
<[email protected]> wrote:
> On 31.05.21 г. 10:53, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: 1434a312 Merge branch 'for-5.13-fixes' of git://git.kernel..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=162843f3d00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=9f3da44a01882e99
> > dashboard link: https://syzkaller.appspot.com/bug?extid=a6bf271c02e4fe66b4e4
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: [email protected]
> >
> > assertion failed: !memcmp(fs_info->fs_devices->fsid, fs_info->super_copy->fsid, BTRFS_FSID_SIZE), in fs/btrfs/disk-io.c:3282
>
> This means a device contains a btrfs filesystem which has a different
> FSID in its superblock than the fsid which all devices part of the same
> fs_devices should have. This can happen in 2 ways - memory corruption
> where either of the ->fsid member are corrupted or if there was a crash
> while a filesystem's fsid was being changed. We need more context about
> what the test did?
Hi Nikolay,
From a semantic point of view we can consider that it just mounts /dev/random.
If syzbot comes up with a reproducer it will post it, but you seem to
already figure out what happened, so I assume you can write a unit
test for this.
On 31.05.21 г. 11:55, Dmitry Vyukov wrote:
> On Mon, May 31, 2021 at 10:44 AM 'Nikolay Borisov' via syzkaller-bugs
> <[email protected]> wrote:
>> On 31.05.21 г. 10:53, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following issue on:
>>>
>>> HEAD commit: 1434a312 Merge branch 'for-5.13-fixes' of git://git.kernel..
>>> git tree: upstream
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=162843f3d00000
>>> kernel config: https://syzkaller.appspot.com/x/.config?x=9f3da44a01882e99
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=a6bf271c02e4fe66b4e4
>>>
>>> Unfortunately, I don't have any reproducer for this issue yet.
>>>
>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>> Reported-by: [email protected]
>>>
>>> assertion failed: !memcmp(fs_info->fs_devices->fsid, fs_info->super_copy->fsid, BTRFS_FSID_SIZE), in fs/btrfs/disk-io.c:3282
>>
>> This means a device contains a btrfs filesystem which has a different
>> FSID in its superblock than the fsid which all devices part of the same
>> fs_devices should have. This can happen in 2 ways - memory corruption
>> where either of the ->fsid member are corrupted or if there was a crash
>> while a filesystem's fsid was being changed. We need more context about
>> what the test did?
>
> Hi Nikolay,
>
> From a semantic point of view we can consider that it just mounts /dev/random.
> If syzbot comes up with a reproducer it will post it, but you seem to
> already figure out what happened, so I assume you can write a unit
> test for this.
>
Well no, under normal circumstances this shouldn't trigger. So if syzbot
is doing something stupid as mounting /dev/random then I don't see a
problem here. The assert is there to catch inconsistencies during normal
operation which doesn't seem to be the case here.
On Mon, May 31, 2021 at 10:57 AM Nikolay Borisov <[email protected]> wrote:
> On 31.05.21 г. 11:55, Dmitry Vyukov wrote:
> > On Mon, May 31, 2021 at 10:44 AM 'Nikolay Borisov' via syzkaller-bugs
> > <[email protected]> wrote:
> >> On 31.05.21 г. 10:53, syzbot wrote:
> >>> Hello,
> >>>
> >>> syzbot found the following issue on:
> >>>
> >>> HEAD commit: 1434a312 Merge branch 'for-5.13-fixes' of git://git.kernel..
> >>> git tree: upstream
> >>> console output: https://syzkaller.appspot.com/x/log.txt?x=162843f3d00000
> >>> kernel config: https://syzkaller.appspot.com/x/.config?x=9f3da44a01882e99
> >>> dashboard link: https://syzkaller.appspot.com/bug?extid=a6bf271c02e4fe66b4e4
> >>>
> >>> Unfortunately, I don't have any reproducer for this issue yet.
> >>>
> >>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> >>> Reported-by: [email protected]
> >>>
> >>> assertion failed: !memcmp(fs_info->fs_devices->fsid, fs_info->super_copy->fsid, BTRFS_FSID_SIZE), in fs/btrfs/disk-io.c:3282
> >>
> >> This means a device contains a btrfs filesystem which has a different
> >> FSID in its superblock than the fsid which all devices part of the same
> >> fs_devices should have. This can happen in 2 ways - memory corruption
> >> where either of the ->fsid member are corrupted or if there was a crash
> >> while a filesystem's fsid was being changed. We need more context about
> >> what the test did?
> >
> > Hi Nikolay,
> >
> > From a semantic point of view we can consider that it just mounts /dev/random.
> > If syzbot comes up with a reproducer it will post it, but you seem to
> > already figure out what happened, so I assume you can write a unit
> > test for this.
> >
>
> Well no, under normal circumstances this shouldn't trigger. So if syzbot
> is doing something stupid as mounting /dev/random then I don't see a
> problem here. The assert is there to catch inconsistencies during normal
> operation which doesn't seem to be the case here.
Does this mean that CONFIG_BTRFS_ASSERT needs to be disabled in any testing?
What is it intended for? Or it can only be enabled when mounting known
good images? But then I assume even btrfs unit tests mount some
invalid images, so it would mean it can't be used even during unit
testing?
Looking at the output of "grep ASSERT fs/btrfs/*.c" it looks like most
of these actually check for something that "must never happen". E.g.
some lists/pointers are empty/non-empty in particular states. And
"must never happen" checks are for testing scenarios...
Taking this particular FSID mismatch assert, should such corrupted
images be mounted for end users? Should users be notified? Currently
they are mounted and users are not notified, what is the purpose of
this assertion?
Perhaps CONFIG_BTRFS_ASSERT needs to be split into "must never happen"
checks that are enabled during testing and normal if's with pr_err for
user notifications?
On 31.05.21 г. 12:09, Dmitry Vyukov wrote:
> On Mon, May 31, 2021 at 10:57 AM Nikolay Borisov <[email protected]> wrote:
>> On 31.05.21 г. 11:55, Dmitry Vyukov wrote:
>>> On Mon, May 31, 2021 at 10:44 AM 'Nikolay Borisov' via syzkaller-bugs
>>> <[email protected]> wrote:
>>>> On 31.05.21 г. 10:53, syzbot wrote:
>>>>> Hello,
>>>>>
>>>>> syzbot found the following issue on:
>>>>>
>>>>> HEAD commit: 1434a312 Merge branch 'for-5.13-fixes' of git://git.kernel..
>>>>> git tree: upstream
>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=162843f3d00000
>>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=9f3da44a01882e99
>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=a6bf271c02e4fe66b4e4
>>>>>
>>>>> Unfortunately, I don't have any reproducer for this issue yet.
>>>>>
>>>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>>>> Reported-by: [email protected]
>>>>>
>>>>> assertion failed: !memcmp(fs_info->fs_devices->fsid, fs_info->super_copy->fsid, BTRFS_FSID_SIZE), in fs/btrfs/disk-io.c:3282
>>>>
>>>> This means a device contains a btrfs filesystem which has a different
>>>> FSID in its superblock than the fsid which all devices part of the same
>>>> fs_devices should have. This can happen in 2 ways - memory corruption
>>>> where either of the ->fsid member are corrupted or if there was a crash
>>>> while a filesystem's fsid was being changed. We need more context about
>>>> what the test did?
>>>
>>> Hi Nikolay,
>>>
>>> From a semantic point of view we can consider that it just mounts /dev/random.
>>> If syzbot comes up with a reproducer it will post it, but you seem to
>>> already figure out what happened, so I assume you can write a unit
>>> test for this.
>>>
>>
>> Well no, under normal circumstances this shouldn't trigger. So if syzbot
>> is doing something stupid as mounting /dev/random then I don't see a
>> problem here. The assert is there to catch inconsistencies during normal
>> operation which doesn't seem to be the case here.
>
>
> Does this mean that CONFIG_BTRFS_ASSERT needs to be disabled in any testing?
> What is it intended for? Or it can only be enabled when mounting known
> good images? But then I assume even btrfs unit tests mount some
> invalid images, so it would mean it can't be used even during unit
> testing?
>
> Looking at the output of "grep ASSERT fs/btrfs/*.c" it looks like most
> of these actually check for something that "must never happen". E.g.
> some lists/pointers are empty/non-empty in particular states. And
> "must never happen" checks are for testing scenarios...
>
> Taking this particular FSID mismatch assert, should such corrupted
> images be mounted for end users? Should users be notified? Currently
> they are mounted and users are not notified, what is the purpose of
> this assertion?
>
> Perhaps CONFIG_BTRFS_ASSERT needs to be split into "must never happen"
> checks that are enabled during testing and normal if's with pr_err for
> user notifications?
>
After going through the code you've convinced me. I just sent a patch
turning the 2 debugging asserts into full-fledged checks in
validate_super. So now the correct behavior is to prevent mounting of
such images. How can I force syzbot to retest with the given patch applied?
On Mon, May 31, 2021 at 11:27 AM Nikolay Borisov <[email protected]> wrote:
> >>>>>
> >>>>> syzbot found the following issue on:
> >>>>>
> >>>>> HEAD commit: 1434a312 Merge branch 'for-5.13-fixes' of git://git.kernel..
> >>>>> git tree: upstream
> >>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=162843f3d00000
> >>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=9f3da44a01882e99
> >>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=a6bf271c02e4fe66b4e4
> >>>>>
> >>>>> Unfortunately, I don't have any reproducer for this issue yet.
> >>>>>
> >>>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> >>>>> Reported-by: [email protected]
> >>>>>
> >>>>> assertion failed: !memcmp(fs_info->fs_devices->fsid, fs_info->super_copy->fsid, BTRFS_FSID_SIZE), in fs/btrfs/disk-io.c:3282
> >>>>
> >>>> This means a device contains a btrfs filesystem which has a different
> >>>> FSID in its superblock than the fsid which all devices part of the same
> >>>> fs_devices should have. This can happen in 2 ways - memory corruption
> >>>> where either of the ->fsid member are corrupted or if there was a crash
> >>>> while a filesystem's fsid was being changed. We need more context about
> >>>> what the test did?
> >>>
> >>> Hi Nikolay,
> >>>
> >>> From a semantic point of view we can consider that it just mounts /dev/random.
> >>> If syzbot comes up with a reproducer it will post it, but you seem to
> >>> already figure out what happened, so I assume you can write a unit
> >>> test for this.
> >>>
> >>
> >> Well no, under normal circumstances this shouldn't trigger. So if syzbot
> >> is doing something stupid as mounting /dev/random then I don't see a
> >> problem here. The assert is there to catch inconsistencies during normal
> >> operation which doesn't seem to be the case here.
> >
> >
> > Does this mean that CONFIG_BTRFS_ASSERT needs to be disabled in any testing?
> > What is it intended for? Or it can only be enabled when mounting known
> > good images? But then I assume even btrfs unit tests mount some
> > invalid images, so it would mean it can't be used even during unit
> > testing?
> >
> > Looking at the output of "grep ASSERT fs/btrfs/*.c" it looks like most
> > of these actually check for something that "must never happen". E.g.
> > some lists/pointers are empty/non-empty in particular states. And
> > "must never happen" checks are for testing scenarios...
> >
> > Taking this particular FSID mismatch assert, should such corrupted
> > images be mounted for end users? Should users be notified? Currently
> > they are mounted and users are not notified, what is the purpose of
> > this assertion?
> >
> > Perhaps CONFIG_BTRFS_ASSERT needs to be split into "must never happen"
> > checks that are enabled during testing and normal if's with pr_err for
> > user notifications?
>
> After going through the code you've convinced me. I just sent a patch
> turning the 2 debugging asserts into full-fledged checks in
> validate_super. So now the correct behavior is to prevent mounting of
> such images. How can I force syzbot to retest with the given patch applied?
syzbot can test patches for issues with reproducers:
http://bit.do/syzbot#testing-patches
but this issue doesn't have a reproducer unfortunately. But I hope
this change is going to be reasonably straightforward. And if/when
this issue happens again after this report is closed with a fix,
syzbot will notify us again. So an absence of any new reports from
syzbot will implicitly mean that everything is fine.
On Mon, May 31, 2021 at 12:27:05PM +0300, Nikolay Borisov wrote:
> On 31.05.21 г. 12:09, Dmitry Vyukov wrote:
> > On Mon, May 31, 2021 at 10:57 AM Nikolay Borisov <[email protected]> wrote:
> >> On 31.05.21 г. 11:55, Dmitry Vyukov wrote:
> >>> On Mon, May 31, 2021 at 10:44 AM 'Nikolay Borisov' via syzkaller-bugs
> >>> <[email protected]> wrote:
> >>>> On 31.05.21 г. 10:53, syzbot wrote:
> >>>>> Hello,
> >>>>>
> >>>>> syzbot found the following issue on:
> >>>>>
> >>>>> HEAD commit: 1434a312 Merge branch 'for-5.13-fixes' of git://git.kernel..
> >>>>> git tree: upstream
> >>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=162843f3d00000
> >>>>> kernel config: https://syzkaller.appspot.com/x/.config?x=9f3da44a01882e99
> >>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=a6bf271c02e4fe66b4e4
> >>>>>
> >>>>> Unfortunately, I don't have any reproducer for this issue yet.
> >>>>>
> >>>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> >>>>> Reported-by: [email protected]
> >>>>>
> >>>>> assertion failed: !memcmp(fs_info->fs_devices->fsid, fs_info->super_copy->fsid, BTRFS_FSID_SIZE), in fs/btrfs/disk-io.c:3282
> >>>>
> >>>> This means a device contains a btrfs filesystem which has a different
> >>>> FSID in its superblock than the fsid which all devices part of the same
> >>>> fs_devices should have. This can happen in 2 ways - memory corruption
> >>>> where either of the ->fsid member are corrupted or if there was a crash
> >>>> while a filesystem's fsid was being changed. We need more context about
> >>>> what the test did?
> >>>
> >>> Hi Nikolay,
> >>>
> >>> From a semantic point of view we can consider that it just mounts /dev/random.
> >>> If syzbot comes up with a reproducer it will post it, but you seem to
> >>> already figure out what happened, so I assume you can write a unit
> >>> test for this.
> >>
> >> Well no, under normal circumstances this shouldn't trigger. So if syzbot
> >> is doing something stupid as mounting /dev/random then I don't see a
> >> problem here. The assert is there to catch inconsistencies during normal
> >> operation which doesn't seem to be the case here.
> >
> > Does this mean that CONFIG_BTRFS_ASSERT needs to be disabled in any testing?
> > What is it intended for? Or it can only be enabled when mounting known
> > good images? But then I assume even btrfs unit tests mount some
> > invalid images, so it would mean it can't be used even during unit
> > testing?
> >
> > Looking at the output of "grep ASSERT fs/btrfs/*.c" it looks like most
> > of these actually check for something that "must never happen". E.g.
> > some lists/pointers are empty/non-empty in particular states. And
> > "must never happen" checks are for testing scenarios...
> >
> > Taking this particular FSID mismatch assert, should such corrupted
> > images be mounted for end users? Should users be notified? Currently
> > they are mounted and users are not notified, what is the purpose of
> > this assertion?
> >
> > Perhaps CONFIG_BTRFS_ASSERT needs to be split into "must never happen"
> > checks that are enabled during testing and normal if's with pr_err for
> > user notifications?
>
> After going through the code you've convinced me. I just sent a patch
> turning the 2 debugging asserts into full-fledged checks in
> validate_super. So now the correct behavior is to prevent mounting of
> such images. How can I force syzbot to retest with the given patch applied?
Let me answer the points from the discussions:
- mounting /dev/random should never lead to a crash, this is effectively
the same as crafting data that would get past the sanity checks
- the behaviour regarding assertions should not affect testing, same
result with or without it
- input validation - for a filesystem everything that comes from the
disk is input, so what we want to do with the data is unconditional
runtime validation
- the 'must never happen' is two fold, depending what's the answer, but
we namely use it to verify invariants and catch developer errors, eg.
adding an object to list and then later assserting that it's there;
excluding the cosmic rays type of bugs, the remaining reason is that
the assert should be turned into a runtime check