linux-kernel - Re: what trees/branches to test on syzbot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 26 Jun 2018 10:16:02 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        Guenter Roeck <groeck@...gle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        syzkaller <syzkaller@...glegroups.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        David Miller <davem@...emloft.net>,
        Wu Fengguang <fengguang.wu@...el.com>
Subject: Re: what trees/branches to test on syzbot

On Tue, Jun 26, 2018 at 07:54:53PM +0900, Tetsuo Handa wrote:
> I hope we can accept NOW either "reviving linux-next.git" or "allowing debug printk()
> patches for linux.git". For example, "INFO: task hung in __sb_start_write" got 900
> crashes in 81 days but still unable to find a reproducer. Dmitry tried to reproduce
> locally with debug printk() patches but not yet successful. I think that testing with
> http://lkml.kernel.org/r/f91e1c82-9693-cca3-4ab7-ecd9d9881fb4@i-love.sakura.ne.jp
> on linux.git or linux-next.git is the only realistic way for debugging this bug.
> More we postpone revival of the linux-next, more syzbot reports we will get...

Here's a proposal for adding linux-next back:

*) Subsystems or maintainers need to have a way to opt out of getting
   spammed with Syzkaller reports that have no reproducer.  More often
   than not, they are not actionable, and just annoy the maintainers,
   with the net result that they tune out all Syzkaller reports as
   noise.

*) Email reports for failures on linux-next that correspond to known
   failures on mainline should be suppressed.  Another way of doing
   this would be to only report a problem found by a specific
   reproducer to the mailing list unless the recipient has agreed to
   be spammed by Syskaller noise.

And please please please, Syzkaller needs to figure out how to do
bisection runs once you have a reproducer.

						- Ted