Message-ID: <20180116071225.GJ8249@thunk.org>
Date:   Tue, 16 Jan 2018 02:12:25 -0500
From:   Theodore Ts'o <tytso@....edu>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Dmitry Vyukov <dvyukov@...gle.com>, Pavel Machek <pavel@....cz>,
        Mike Galbraith <efault@....de>,
        LKML <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        syzkaller <syzkaller@...glegroups.com>
Subject: Re: LKML admins (syzbot emails are not delivered)

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.  <Face palm>

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

Powered by blists - more mailing lists