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]
Message-ID: <873735n3dy.fsf@xmission.com>
Date:   Tue, 16 Jan 2018 11:02:17 -0600
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Guenter Roeck <groeck@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "Theodore Ts'o" <tytso@....edu>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        syzkaller <syzkaller@...glegroups.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        David Miller <davem@...emloft.net>,
        Fengguang Wu <fengguang.wu@...el.com>
Subject: Re: what trees/branches to test on syzbot

Dmitry Vyukov <dvyukov@...gle.com> writes:

> On Tue, Jan 16, 2018 at 10:45 AM, Guenter Roeck <groeck@...gle.com> wrote:
>> On Mon, Jan 15, 2018 at 11:51 PM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
>>> Hello,
>>>
>>> Several people proposed that linux-next should not be tested on
>>> syzbot. While some people suggested that it needs to test as many
>>> trees as possible. I've initially included linux-next as it is a
>>> staging area before upstream tree, with the intention that patches are
>>> _tested_ there, is they are not tested there, bugs enter upstream
>>> tree. And then it takes much longer to get fix into other trees.
>>>
>>> So the question is: what trees/branches should be tested? Preferably
>>> in priority order as syzbot can't test all of them.
>>>
>>
>> I always thought that -next existed specifically to give people a
>> chance to test the code in it. Maybe the question is where to report
>> the test results ?
>
> FTR, from Guenter on another thread:
>
>> Interesting. Assuming that refers to linux-next, not linux-net, that
>> may explain why linux-next tends to deteriorate. I wonder if I should
>> drop it from my testing as well. I'll be happy to follow whatever the
>> result of this exchange is and do the same.
>
> If we agree on some list of important branches, and what branches
> specifically should not be tested with automatic reporting, I think it
> will benefit everybody.
> +Fengguang, can you please share your list and rationale behind it?

The problem is testing linux-next and then using get-maintainer.pl to
report the problem.

If you are resource limited I would start by testing Linus's tree to
find the existing bugs, and to get a baseline.  Using get-maintainer.pl
is fine for sending emails to developers there.

After that I would test the individual tress that are pulled into
linux-next.  So that any issue not found in Linus's tree can be
attributed to the tree you are testing and sent the the appropriate
maintainer.

After that I would consider testing linux-next itself and see if any
issues are caused by the merger of all of those trees.

Eric

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ