public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Dmitry Vyukov <dvyukov@google.com>, Pavel Machek <pavel@ucw.cz>,
	Mike Galbraith <efault@gmx.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	syzkaller <syzkaller@googlegroups.com>
Subject: Re: LKML admins (syzbot emails are not delivered)
Date: Tue, 16 Jan 2018 02:12:25 -0500	[thread overview]
Message-ID: <20180116071225.GJ8249@thunk.org> (raw)
In-Reply-To: <87efmrt6ul.fsf@xmission.com>

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

  reply	other threads:[~2018-01-16  7:12 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-04  9:09 LKML admins (syzbot emails are not delivered) Dmitry Vyukov
2018-01-04  9:23 ` Greg Kroah-Hartman
2018-01-04  9:56   ` Ozgur
2018-01-04 15:31     ` David Miller
2018-01-04 19:11       ` Ozgur
2018-01-04 11:03   ` Dmitry Vyukov
2018-01-04 11:04     ` Dmitry Vyukov
2018-01-04 11:20       ` Greg Kroah-Hartman
2018-01-04 15:35         ` David Miller
2018-01-15  9:43           ` Dmitry Vyukov
2018-03-01 16:22         ` Dmitry Vyukov
2018-03-08 20:03           ` David Miller
2018-03-12  8:56             ` Dmitry Vyukov
2018-03-12 14:03               ` David Miller
2018-01-04 23:50       ` Theodore Ts'o
2018-01-08 12:01         ` Dmitry Vyukov
2018-01-08 12:11         ` Dmitry Vyukov
2018-01-04  9:25 ` Pavel Machek
2018-01-04  9:38   ` Mike Galbraith
2018-01-04  9:56     ` Pavel Machek
2018-01-04 11:09       ` Dmitry Vyukov
2018-01-04 11:18         ` Pavel Machek
2018-01-15 10:08           ` Dmitry Vyukov
2018-01-15 13:08             ` Pavel Machek
2018-01-15 13:38               ` Dmitry Vyukov
2018-01-15 13:53                 ` Pavel Machek
2018-01-04 15:23         ` Eric W. Biederman
2018-01-15 10:54           ` Dmitry Vyukov
2018-01-15 12:54             ` Pavel Machek
2018-01-15 13:02               ` Dmitry Vyukov
2018-01-15 16:16                 ` Eric W. Biederman
2018-01-16 18:01                   ` Dmitry Vyukov
2018-01-15 16:38             ` Eric W. Biederman
2018-01-16  7:12               ` Theodore Ts'o [this message]
2018-01-16  7:51                 ` Dmitry Vyukov
2018-01-16  9:52                   ` Guenter Roeck
2018-01-16  9:56                     ` Dmitry Vyukov
2018-01-16  9:58                       ` Guenter Roeck
2018-01-16  7:59                 ` Dmitry Vyukov
2018-01-16 11:19                   ` Fengguang Wu
2018-01-16  8:31                 ` Dmitry Vyukov
2018-01-16 23:13                   ` Theodore Ts'o
2018-01-17  8:06                     ` Dmitry Vyukov
2018-01-17 16:53                       ` Theodore Ts'o
2018-01-17 17:16                         ` Dmitry Vyukov
2018-01-17 22:27                           ` Bernd Petrovitsch
2018-01-16  8:34                 ` Dmitry Vyukov
2018-01-24 16:04                   ` Alan Cox
2018-01-24 17:06                     ` Eric W. Biederman
2018-01-24 17:32                       ` Greg Kroah-Hartman
2018-01-16 18:20               ` Dmitry Vyukov
2018-01-17  8:13               ` Dmitry Vyukov
2018-01-04 21:38         ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180116071225.GJ8249@thunk.org \
    --to=tytso@mit.edu \
    --cc=akpm@linux-foundation.org \
    --cc=dvyukov@google.com \
    --cc=ebiederm@xmission.com \
    --cc=efault@gmx.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=syzkaller@googlegroups.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox