Re: LKML admins (syzbot emails are not delivered)

[Dmitry Vyukov]

On Thu, Jan 4, 2018 at 12:18 PM, Pavel Machek <pavel@xxxxxx> wrote:
> On Thu 2018-01-04 12:09:26, Dmitry Vyukov wrote:
>> On Thu, Jan 4, 2018 at 10:56 AM, Pavel Machek <pavel@xxxxxx> wrote:
>> >> On Thu, 2018-01-04 at 10:25 +0100, Pavel Machek wrote:
>> >> > Hi!
>> >> > >
>> >> > > Some of syzbot emails don't appear on LKML mailing lists, while they
>> >> > > were mailed as any other emails. Here are few examples:
>> >> > >
>> >> > > "KASAN: use-after-free Read in rds_tcp_dev_event"
>> >> > > https://groups.google.com/d/msg/syzkaller-bugs/nEeIAsNLWL4/1GzamOmRAwAJ
>> >> > >
>> >> > > "general protection fault in __wake_up_common"
>> >> > > https://groups.google.com/d/msg/syzkaller-bugs/4TrrZ0bIViw/rBcYLUJHAgAJ
>> >> > >
>> >> > > Does anybody know how to get in contact with real people behind LKML
>> >> > > and/or bugzilla?
>> >> >
>> >> > Not delivering syzbot emails might be good thing?
>> >>
>> >> Nah, the thing is finding and reporting bugs just like a human would,
>> >> it just doesn't need sleep etc, so sometimes reports more than humans
>> >> can keep up with.  It needs a smarter brother.. but then again, maybe
>> >> not, if bots start fixing things too, a lot of meatware hackers would
>> >> have to go find real jobs.
>> >
>> > Sending random, unrepeatable Oopses to lkml is not what humans would
>> > do, and perhaps not something bots should do, either.
>>
>>
>> Hi Pavel,
>>
>> I've answered this question here in full detail. In short, this is
>> useful and actionable.
>> https://groups.google.com/d/msg/syzkaller/2nVn_XkVhEE/GjjfISejCgAJ
>
> I've already deleted many such reports from my lkml folder. It
> definitely is below quality of normal bug reports.


Pavel, if you point to exact deficiencies in the process and propose
ways to improve it, we can turn this into a positive, constructive and
actionable discussion.

In lots of cases (~50%) quality of syzbot reports is equal to human
reports, or _higher_.
It provides exact kernel commit, config, compiler, stand-alone C
reproducer and a nice, symbolized report even with inline frames. You
don't always get all of this from human reports.

In the remaining cases (no reproducer), quality of syzbot reports is
the _same_ as for human reports.
Say, your machine randomly crashes. You reboot it, but it crashes
again after some time. You try to repeat what you did before the crash
(say, opened a particular web page), but it does not reproduce the
crash. But one way or another, it happened and it's a kernel bug (you
did not write garbage into /dev/mem, nor loaded untested kernel
modules). What do you do in such case? Right, you report what you know
about the bug (kernel crash message, kernel revision and config).
As I said before, in lots of cases (I would say ~2/3), kernel crash
reports are actionable on its own. For example, KASAN/LOCKDEP reports
contain enough context to localize a bug. Lots of WARNINGs/GPFs point
to simple missed input checks or off-by-one's. So it would be wrong to
hide them, keep them private and pretend that nothing happened.