Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750821AbeAPHMd (ORCPT + 1 other); Tue, 16 Jan 2018 02:12:33 -0500 Received: from imap.thunk.org ([74.207.234.97]:51406 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750716AbeAPHMc (ORCPT ); Tue, 16 Jan 2018 02:12:32 -0500 Date: Tue, 16 Jan 2018 02:12:25 -0500 From: Theodore Ts'o To: "Eric W. Biederman" Cc: Dmitry Vyukov , Pavel Machek , Mike Galbraith , LKML , Greg Kroah-Hartman , Andrew Morton , Linus Torvalds , syzkaller Subject: Re: LKML admins (syzbot emails are not delivered) Message-ID: <20180116071225.GJ8249@thunk.org> Mail-Followup-To: Theodore Ts'o , "Eric W. Biederman" , Dmitry Vyukov , Pavel Machek , Mike Galbraith , LKML , Greg Kroah-Hartman , Andrew Morton , Linus Torvalds , syzkaller References: <20180104092552.GA991@amd> <1515058705.7875.25.camel@gmx.de> <20180104095628.GA4407@atrey.karlin.mff.cuni.cz> <87inchsl4h.fsf@xmission.com> <87efmrt6ul.fsf@xmission.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87efmrt6ul.fsf@xmission.com> User-Agent: Mutt/1.9.2 (2017-12-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Mon, Jan 15, 2018 at 10:38:42AM -0600, Eric W. Biederman wrote: > > Sometimes the branches on linux-next are experimental crap. If someone > adds an experimental memory allocator to linux-next before discovering > it causes all kinds of problems I don't want bug reports about my code > not being able to allocate memory because the memory allocator was bad. > > If you don't have the resources to test the individual branches of > linux-next please just test Linus's tree. That will be much more > meaningful and productive. I have to agree with Eric here, the reason why Fengguang Wu's 0-day testing robot is much better received by developers is that he does not test linux-net, but rather individual subsystem git trees and branches. His test automation also does an automatic bisection search, and can point at a specific commit --- at which point e-mail goes out to owner of the subsystem git tree, and to the people who authored and/or reviewed the guilty commit. Dmitry, perhaps you could collaborate with Intel's 0-day testing folks? They have code which does all of this, and perhaps it can be leveraged. > > When I made the complaint it came to me and to messages on lkml as > .log. With Content-Type: Application/Octent-stream. > > That is a bloody mess that wastes peoples time. If it is fixed good, > it certainly was not fixed at that point. I just checked a recent report from the Syzbot, and it's not fixed. The raw.log file still uses a Content-Type of Application/Octet-stream. Worse the reproducer C source file has a content type of Application/Octet-stream instead of the much more sane Application/text. Hint to Googlers --- many kernel developers do not use Gmail because it does unspeakable things to whitespaces, which results in mangled patches, or because they want real mail threading. The Content-Type really matters, because for many text-based Mail User Agents, if it is Application/octet-stream, the MUA will assume that it can't be displayed as text, and require that it be saved to a file, which the developer then has to manually read by firing up a pager or an editor. When you are getting hundreds or thousands of messages a day, having critical data which darn well *could* be displayed as text require manual processing adds friction and destroys developer productivity. So *you* might think the Content-type is trivial, but for developers who live in their MUA's (that's why many prefer to review patches in their mail reader, and not have to switch to web browser to use Gerrit), screwing up the Content-type is going to be a big deal to them. > Outside of the bugs being considered as considered as security issues, > the bugs syzbot finds are generally things that don't affect anyone in > practice. So are very low on the priority of things to get fixed. The real danger is that people will start auto-filing Syzbot reports to "file 13" (e.g., the trash can) because they are too annoying.... But that's Dmitry and the Syzkaller team's problem, not the kernel developers. :-) - Ted