On Thu, Dec 27, 2018 at 6:28 AM Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote:
>
> Lots of kernel bug reports routinely get lost on mailing lists, which is bad.
Nobody reads the kernel mailing list directly - there's just too much traffic.
And honestly, even fewer people then read the syzbot reports, because
they are so illegible and inhuman. They're better than they used to
be, but they are still basically impossible to parse without a lot of
effort.
And no, syzbot didn't really report the bug with any specificity - it
wasn't clear *which* commit it was that caused it, so reading that
syzbot report, at no point was it then obvious that the original patch
had issues.
See the problem?
So the issue seems to be that syzbot is simply not useful enough. It's
output is too rough for people to take it seriously. You see how the
report by Wei Wu then got traction, because Wei took a syzbot report
and added some human background and distilled it down to not be
"here's a big dump of random information".
So I suspect syzbot should strive to make for a much stronger
signal-to-noise ratio. For example, if syzbot had actually bisected
the bug it reported, that would have been quite a strong signal.
Compare these two emails:
https://lore.kernel.org/lkml/1542702858-4318-1-git-send-email-wanpengli@xxxxxxxxxxx/
https://lore.kernel.org/lkml/0000000000001c7a5c0573607583@xxxxxxxxxx/
and note the absolutely huge difference in actual *information* (as
opposed to raw data).
Any possibility that syzbot would actually do the bisection once it
finds a problem, and write a report based on the commit that caused
the problem rather than just a problem dump?
Linus
