All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Guenter Roeck <groeck@google.com>,
	"Theodore Ts'o" <tytso@mit.edu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	linux-kernel <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>,
	kbuild test robot <fengguang.wu@intel.com>
Subject: Re: what trees/branches to test on syzbot
Date: Thu, 5 Jul 2018 19:49:10 +0900	[thread overview]
Message-ID: <8c9027d6-ead2-1cca-4410-c8dbbe4bf2ea@I-love.SAKURA.ne.jp> (raw)
In-Reply-To: <876e38d9-95e5-0a93-9c26-7287151b8b53@i-love.sakura.ne.jp>

On 2018/06/27 5:37, Tetsuo Handa wrote:
> I think that syzbot can stop deciding email recipients and leave it to those who
> diagnose bugs, for the ratio of sending to wrong subsystem maintainers is not low.
> For example, syzbot assumed that "INFO: task hung in __get_super" is a fs layer bug.
> But I think that the problem is in more lower layers (block or mm or locking layer).
> The root cause could even be just overstressed due to instructions enabled by
> CONFIG_KCOV_ENABLE_COMPARISONS=y.
> 

Thinking from today's bpf related reports, I think that subversion/quilt-based
custom patches will be useful as well.

Since quilt can apply changes in a patch atomically (using "quilt push" command),
we can maintain one custom patch for one git tree. Then, the kernel source syzbot
will test is either "no custom patch applied" or "only one custom patch applied".
That is, if "quilt push" fails, syzbot will continue testing without custom patch.

Since subversion manages revision number using an integer, adding a column for
indicating "which custom patch was applied for this report" to the table will not
occupy much space. We will figure out that custom patch needs to be updated via
syzbot reports with that column being empty.

The custom patch can contain whatever changes which might be useful for debugging.
For example, debug printk() for "INFO: task hung in __sb_start_write" case.
For another example, context identifier for printk().

Updating custom patches in subversion repository is done manually. But the cost is
negligible.

  reply	other threads:[~2018-07-05 10:50 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 [this message]
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=8c9027d6-ead2-1cca-4410-c8dbbe4bf2ea@I-love.SAKURA.ne.jp \
    --to=penguin-kernel@i-love.sakura.ne.jp \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=dvyukov@google.com \
    --cc=ebiederm@xmission.com \
    --cc=fengguang.wu@intel.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.