[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+abQSWfiN16BwXFOBi+d3CFGk53oj+5+zZwQPbcYu-Rew@mail.gmail.com>
Date: Thu, 28 Nov 2019 09:54:15 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Sven Eckelmann <sven@...fation.org>
Cc: syzkaller <syzkaller@...glegroups.com>,
syzbot <syzbot+a229d8d995b74f8c4b6c@...kaller.appspotmail.com>,
a@...table.cc, b.a.t.m.a.n@...ts.open-mesh.org,
David Miller <davem@...emloft.net>,
Jakub Kicinski <jakub.kicinski@...ronome.com>,
Jamal Hadi Salim <jhs@...atatu.com>,
Jiří Pírko <jiri@...nulli.us>,
LKML <linux-kernel@...r.kernel.org>, mareklindner@...mailbox.ch,
netdev <netdev@...r.kernel.org>, sw@...onwunderlich.de,
syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
vinicius.gomes@...el.com, wang.yi59@....com.cn,
Cong Wang <xiyou.wangcong@...il.com>
Subject: Re: WARNING in mark_lock (3)
On Thu, Nov 28, 2019 at 9:46 AM Sven Eckelmann <sven@...fation.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@...fation.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"?
Powered by blists - more mailing lists