Re: BUG: soft lockup in kvm_vm_release

[Dmitry Vyukov <dvyukov@google.com>]

On Sun, Mar 24, 2019 at 1:04 AM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Sat, 23 Mar 2019, syzbot wrote:
>
> > syzbot has bisected this bug to:
> >
> > commit 80eb865768703c0f85a0603762742ae1dedf21f0
> > Author: Andrea Parri <andrea.parri@amarulasolutions.com>
> > Date:   Tue Nov 27 11:01:10 2018 +0000
> >
> >    sched/fair: Clean up comment in nohz_idle_balance()
>
> I.m pretty sure that this bisect is bogus. The commit changes a comment not
> code.
>
> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1362209b200000
> > start commit:   57902dc0 Merge tag 'riscv-for-linus-5.0-rc7' of git://git...
> > git tree:       upstream
> > final crash:    https://syzkaller.appspot.com/x/report.txt?x=10e2209b200000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1762209b200000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=ee434566c893c7b1
> > dashboard link: https://syzkaller.appspot.com/bug?extid=6349a512c2938b2ad058
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=14287e78c00000
> >
> > Reported-by: syzbot+6349a512c2938b2ad058@syzkaller.appspotmail.com
> > Fixes: 80eb86576870 ("sched/fair: Clean up comment in nohz_idle_balance()")
> >
> > For information about bisection process see: https://goo.gl/tpsmEJ#bisection
>
> If I understand that correctly, then the bisect does not try to revert the
> commit which it identified on top of the tree where it started to bisect.
>
> I think that'd be a reasonably simple to do extra data point, at least when
> the commit reverts cleanly on head.

Hi Thomas,

Interesting. You mean revert on the start commit and check if kernel
still crashes?

I've got several suggestions on how some results can be tentatively
marked as "suspicious". But the question is: if we mark a result as
"suspicious", what then? How should reporting be different or what?
If syzbot does not report bisection results, people start complaining
"why there are no bisection results?"; "why didn't syzbot just bisect
it to find the right people to CC?"; or even that this does not count
as a bug report without bisection.
So we are kind of between 2 fires here.
And this test will have false positives too. I can see at least 3
common reasons for this:
 - reproducer triggering 2+ bugs at the same time
 - unrelated kernel bug that triggers of simple programs, or fires
episodically on random programs
 - if we found the right commit and it itself fixes a bug in the
subsystem, then we will now hit that bug instead
So in a sense we will just add more flakiness on top of flakiness,
potentially making the whole thing even more nonsensical. E.g. we can
find the right commit, but then say that it's wrong.

But I am adding this to
https://github.com/google/syzkaller/issues/1051 where I am collecting
all feedback/ideas re bisection.