All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fengguang Wu <fengguang.wu@intel.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Guenter Roeck <groeck@google.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Theodore Ts'o <tytso@mit.edu>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	syzkaller <syzkaller@googlegroups.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	David Miller <davem@davemloft.net>
Subject: Re: what trees/branches to test on syzbot
Date: Fri, 19 Jan 2018 09:48:03 +0800	[thread overview]
Message-ID: <20180119014803.n75l5vrxlpifm3sc@wfg-t540p.sh.intel.com> (raw)
In-Reply-To: <CACT4Y+aGMoobn069+Lq1BT2YGqi9qYY9vHFtiXT2DLsJ5ZUh9Q@mail.gmail.com>

Hi Dmitry,

On Tue, Jan 16, 2018 at 10:58:51AM +0100, Dmitry Vyukov wrote:
>On Tue, Jan 16, 2018 at 10:45 AM, Guenter Roeck <groeck@google.com> wrote:
>> On Mon, Jan 15, 2018 at 11:51 PM, Dmitry Vyukov <dvyukov@google.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?

0-day aims to aggressively test as much tree and branches as possible,
including various developer trees, maintainer, linux-next, mainline and
stable trees. Here are the complete list of 800+ trees we monitored:

https://git.kernel.org/pub/scm/linux/kernel/git/wfg/lkp-tests.git/tree/repo/linux

The rationale is obvious. IMHO what really matters here is about
capability rather than rationale: that policy heavily relies on the
fundamental capability of auto bisecting. Once regressions are
bisected, we know the owners of problem to auto send report to, ie.
the first bad commit's author and committer.

For the bugs that cannot be bisected, they tend to be old ones and
we report more often on mainline tree than linux-next.

Thanks,
Fengguang

  parent reply	other threads:[~2018-01-19  1:48 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-16  7:51 what trees/branches to test on syzbot Dmitry Vyukov
2018-01-16  9:45 ` Guenter Roeck
2018-01-16  9:58   ` Dmitry Vyukov
2018-01-16 16:58     ` Guenter Roeck
2018-01-16 17:02     ` Eric W. Biederman
2018-01-16 17:34       ` Greg Kroah-Hartman
2018-01-22 13:32         ` Dmitry Vyukov
2018-06-09  6:31           ` Tetsuo Handa
2018-06-09 22:17             ` Linus Torvalds
2018-06-10  1:51               ` Theodore Y. Ts'o
2018-06-10  6:11                 ` Dmitry Vyukov
2018-06-11  1:22                   ` Theodore Y. Ts'o
2018-06-15  9:54                     ` Dmitry Vyukov
2018-06-18  4:52                       ` Stephen Rothwell
2018-06-18  6:10                       ` Eric W. Biederman
2018-06-18 13:54                       ` Alan Cox
2018-06-26 10:54               ` Tetsuo Handa
2018-06-26 14:16                 ` Theodore Y. Ts'o
2018-06-26 14:38                   ` Dmitry Vyukov
2018-06-26 14:54                     ` Guenter Roeck
2018-06-26 20:37                       ` Tetsuo Handa
2018-07-05 10:49                         ` Tetsuo Handa
2018-07-06 23:26                           ` Tetsuo Handa
2018-07-10  0:35                             ` Andrew Morton
2018-07-10  2:13                               ` Tetsuo Handa
2018-01-19  1:48     ` Fengguang Wu [this message]
2018-01-22 13:34       ` Dmitry Vyukov

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=20180119014803.n75l5vrxlpifm3sc@wfg-t540p.sh.intel.com \
    --to=fengguang.wu@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=dvyukov@google.com \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=groeck@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=syzkaller@googlegroups.com \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.