syzbot has bisected this bug to:
commit d665c1281bc89ac85b8b0c058c22a3f94640a1d6 Author: Yi Wang wang.yi59@zte.com.cn Date: Mon Oct 21 23:57:42 2019 +0000
net: sched: taprio: fix -Wmissing-prototypes warnings
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=132ee536e00000 start commit: 89d57ddd Merge tag 'media/v5.5-1' of git://git.kernel.org/.. git tree: upstream final crash: https://syzkaller.appspot.com/x/report.txt?x=10aee536e00000 console output: https://syzkaller.appspot.com/x/log.txt?x=172ee536e00000 kernel config: https://syzkaller.appspot.com/x/.config?x=595c15c951695d1b dashboard link: https://syzkaller.appspot.com/bug?extid=a229d8d995b74f8c4b6c syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1511af5ee00000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=16e0f17ae00000
Reported-by: syzbot+a229d8d995b74f8c4b6c@syzkaller.appspotmail.com Fixes: d665c1281bc8 ("net: sched: taprio: fix -Wmissing-prototypes warnings")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
On Thursday, 28 November 2019 03:00:01 CET syzbot wrote: [...]
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=132ee536e00000 start commit: 89d57ddd Merge tag 'media/v5.5-1' of git://git.kernel.org/.. git tree: upstream final crash: https://syzkaller.appspot.com/x/report.txt?x=10aee536e00000
Can the syzbot infrastructure be told to ignore this crash in the bisect run? Because this should be an unrelated crash which is (hopefully) fixed in 40e220b4218b ("batman-adv: Avoid free/alloc race when handling OGM buffer").
Kind regards, Sven
On Thu, Nov 28, 2019 at 8:25 AM Sven Eckelmann sven@narfation.org wrote:
On Thursday, 28 November 2019 03:00:01 CET syzbot wrote: [...]
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=132ee536e00000 start commit: 89d57ddd Merge tag 'media/v5.5-1' of git://git.kernel.org/.. git tree: upstream final crash: https://syzkaller.appspot.com/x/report.txt?x=10aee536e00000
Can the syzbot infrastructure be told to ignore this crash in the bisect run? Because this should be an unrelated crash which is (hopefully) fixed in 40e220b4218b ("batman-adv: Avoid free/alloc race when handling OGM buffer").
+syzkaller mailing list for syzbot discussion
Hi Sven,
There is no such functionality at the moment. What exactly do you mean? Somehow telling it interactively? Or hardcode some set of crashes for linux? I don't see how any of these options can really work...
On Thursday, 28 November 2019 09:40:32 CET Dmitry Vyukov wrote:
On Thu, Nov 28, 2019 at 8:25 AM Sven Eckelmann sven@narfation.org wrote:
On Thursday, 28 November 2019 03:00:01 CET syzbot wrote: [...]
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=132ee536e00000 start commit: 89d57ddd Merge tag 'media/v5.5-1' of git://git.kernel.org/.. git tree: upstream final crash: https://syzkaller.appspot.com/x/report.txt?x=10aee536e00000
Can the syzbot infrastructure be told to ignore this crash in the bisect run? Because this should be an unrelated crash which is (hopefully) fixed in 40e220b4218b ("batman-adv: Avoid free/alloc race when handling OGM buffer").
+syzkaller mailing list for syzbot discussion
Hi Sven,
There is no such functionality at the moment. What exactly do you mean? Somehow telling it interactively? Or hardcode some set of crashes for linux? I don't see how any of these options can really work...
I was thinking more about rerunning the same bisect but tell it to assume "crashed: general protection fault in batadv_iv_ogm_queue_add" as OK instead of assuming that it is a crashed like the previous "crashed: WARNING in mark_lock". Just to get a non-bogus bisect result. Or try to rerun the bisect between 40e220b4218b and 89d57dddd7d319ded00415790a0bb3c954b7e386
Kind regards, Sven
On Thu, Nov 28, 2019 at 9:46 AM Sven Eckelmann sven@narfation.org wrote:
On Thursday, 28 November 2019 09:40:32 CET Dmitry Vyukov wrote:
On Thu, Nov 28, 2019 at 8:25 AM Sven Eckelmann sven@narfation.org wrote:
On Thursday, 28 November 2019 03:00:01 CET syzbot wrote: [...]
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=132ee536e00000 start commit: 89d57ddd Merge tag 'media/v5.5-1' of git://git.kernel.org/.. git tree: upstream final crash: https://syzkaller.appspot.com/x/report.txt?x=10aee536e00000
Can the syzbot infrastructure be told to ignore this crash in the bisect run? Because this should be an unrelated crash which is (hopefully) fixed in 40e220b4218b ("batman-adv: Avoid free/alloc race when handling OGM buffer").
+syzkaller mailing list for syzbot discussion
Hi Sven,
There is no such functionality at the moment. What exactly do you mean? Somehow telling it interactively? Or hardcode some set of crashes for linux? I don't see how any of these options can really work...
I was thinking more about rerunning the same bisect but tell it to assume "crashed: general protection fault in batadv_iv_ogm_queue_add" as OK instead of assuming that it is a crashed like the previous "crashed: WARNING in mark_lock". Just to get a non-bogus bisect result. Or try to rerun the bisect between 40e220b4218b and 89d57dddd7d319ded00415790a0bb3c954b7e386
But... but this done by a program. What do you mean by "tell it"?
On Thursday, 28 November 2019 09:54:15 CET Dmitry Vyukov wrote: [...]
I was thinking more about rerunning the same bisect but tell it to assume "crashed: general protection fault in batadv_iv_ogm_queue_add" as OK instead of assuming that it is a crashed like the previous "crashed: WARNING in mark_lock". Just to get a non-bogus bisect result. Or try to rerun the bisect between 40e220b4218b and 89d57dddd7d319ded00415790a0bb3c954b7e386
But... but this done by a program. What do you mean by "tell it"?
Sorry that I asked about what the infrastructure around syzbot can do and how the interaction with it looks like.
Kind regards, Sven
b.a.t.m.a.n@lists.open-mesh.org
-
Dmitry Vyukov -
Sven Eckelmann -
syzbot