Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755272AbeAOKIg (ORCPT + 1 other); Mon, 15 Jan 2018 05:08:36 -0500 Received: from mail-pl0-f67.google.com ([209.85.160.67]:36114 "EHLO mail-pl0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751990AbeAOKId (ORCPT ); Mon, 15 Jan 2018 05:08:33 -0500 X-Google-Smtp-Source: ACJfBoumt7LXL2oHCoo4RgJHsq6J09EKOhBKvm49Zr62ZVlAiB0Oj+rE98aXXjgM8If2hPbKZWiN9K0p07+bQXEn8Xg= MIME-Version: 1.0 In-Reply-To: <20180104111801.GA2220@amd> References: <20180104092552.GA991@amd> <1515058705.7875.25.camel@gmx.de> <20180104095628.GA4407@atrey.karlin.mff.cuni.cz> <20180104111801.GA2220@amd> From: Dmitry Vyukov Date: Mon, 15 Jan 2018 11:08:12 +0100 Message-ID: Subject: Re: LKML admins (syzbot emails are not delivered) To: Pavel Machek Cc: Mike Galbraith , LKML , Greg Kroah-Hartman , Andrew Morton , Linus Torvalds , syzkaller Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Thu, Jan 4, 2018 at 12:18 PM, Pavel Machek wrote: > On Thu 2018-01-04 12:09:26, Dmitry Vyukov wrote: >> On Thu, Jan 4, 2018 at 10:56 AM, Pavel Machek 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.