The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped automatically by the mailing list software.
--- Begin Message ---On Thu, Nov 28, 2019 at 9:46 AM Sven Eckelmann <s...@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 <s...@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"?
--- End Message ---