All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Dmitry Vyukov <dvyukov@google.com>
Cc: "Theodore Y. Ts'o" <tytso@mit.edu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Guenter Roeck <groeck@google.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	syzkaller <syzkaller@googlegroups.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	David Miller <davem@davemloft.net>,
	Wu Fengguang <fengguang.wu@intel.com>
Subject: Re: what trees/branches to test on syzbot
Date: Mon, 18 Jun 2018 01:10:49 -0500	[thread overview]
Message-ID: <87602gmxp2.fsf@xmission.com> (raw)
In-Reply-To: <CACT4Y+adoSOyhLNuWF7ZCS-e7SxZu89O1VLXV5NZjg_c6U3B-w@mail.gmail.com> (Dmitry Vyukov's message of "Fri, 15 Jun 2018 11:54:16 +0200")

Dmitry Vyukov <dvyukov@google.com> writes:

> On Mon, Jun 11, 2018 at 3:22 AM, Theodore Y. Ts'o <tytso@mit.edu> wrote:
>> On Sun, Jun 10, 2018 at 08:11:05AM +0200, Dmitry Vyukov wrote:
>>>
>>> The set of trees where a crash happened is visible on dashboard, so
>>> one can see if it's only linux-next or whole set of trees. Potentially
>>> syzbot can act differently depending on this predicate, but I don't
>>> see what should be the difference.  However, this does not fully save
>>> from falsely assessing bugs as linux-next-only just because they
>>> happened few times and only on linux-next so far.
>>
>> So how about this, only report something as being a linux-next
>> regression if (a) there is a reproducer, and (b) the reproducer does
>> not trigger any kind of crash on mainline?
>>
>>> There is also a problem with rebasing of linux-next: reported commit
>>> hashes do not make sense and we can forget about bisection.
>>
>> If there is a valid reproducer, bisection should simply be a matter ofu
>> running and if we know the reproducer doesn't trigger on mainline,
>> then the bisection should only require no more than 8-10 VM runs.  For
>> Linux-next, this would be *super* valuable.  Reporting the commit ID
>> and the one-line commit summary will be enough for most maintainers,
>> since even if they are using a rewinding head, so long as the
>> bisection can be done quickly enough (e.g., within a few days), it
>> will still be in their git repository.
>>
>> And if you have a reproducer, then once it's identified as a
>> linux-next reproducer with a guilty commit, that can be confirmed by
>> either (a) seeing if you can revert the commit and if it makes the
>> problem go away, or (b) figure out which subsystem git tree the commit
>> was introduced via, and then verify that the reproducer triggers on
>> the tip of the subsystem git tree.
>>
>> All of this will require development effort, so I suspect it's not
>> something we'll see from syzbot tomorrow --- but it's not
>> *impossible*.
>>
>> I think though that sending e-mail about a linux-next syzbot crash if
>> there is a reproducer and the reproducer doesn't trigger a crash on
>> mainline should be really simple to implement, and it would add huge
>> value without spamming the subsystem maintainers.
>
>
> But if this also happens on upstream, then we want to report it
> twofold. So this predicate can be reduced to "report crashes that
> happen only on linux-next iff they have reproducers", right?
> We will probably also need something that will auto-invalidate old
> bugs that were never reported.
>
> Re backwards bisection (when bug is introduced), we can actually test
> linux-next-history instead of linux-next, right?
> But forward bisection (when bug is fixed) unfortunately won't work
> because these commits are not connected to HEAD. And forward bisection
> is very important, otherwise who will bring order to all these
> hundreds of open bugs?
> https://syzkaller.appspot.com/

Maybe you want to monitor linux-next and see if the problem commits
disappear.  That can let you stop worrying about the issue.

I don't see the point of worrying about which linux-next build a problem
appeared in.  It is the first commit that reproduces the problem that is
interesting.

That commit tells you who did something that was problematic.  If you
notify the committer with the reproducer they should be able to
reproduce the problem and fix it.

Very rarely I suspect it will be the merge commit into linux-next that
is the problem, but most of the time these commits are going to be in
the subsystem trees.

Eric


  parent reply	other threads:[~2018-06-18  6:11 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-16  7:51 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 [this message]
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
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=87602gmxp2.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=dvyukov@google.com \
    --cc=fengguang.wu@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=groeck@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=sfr@canb.auug.org.au \
    --cc=syzkaller@googlegroups.com \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --subject='Re: what trees/branches to test on syzbot' \
    /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

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.