[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180619163624.4sol67vmh7wrfgyo@lakrids.cambridge.arm.com>
Date: Tue, 19 Jun 2018 17:36:25 +0100
From: Mark Rutland <mark.rutland@....com>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: "Theodore Y. Ts'o" <tytso@....edu>,
LKML <linux-kernel@...r.kernel.org>,
syzkaller <syzkaller@...glegroups.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: An example of a much more impactful way of doing file
system-specific fuzzing
Hi Dmitry,
I hope the below doesn't sound like a criticism; I am a *huge* fan of
syzkaller.
On Tue, Jun 19, 2018 at 06:18:07PM +0200, 'Dmitry Vyukov' via syzkaller wrote:
> On Mon, Jun 18, 2018 at 7:15 AM, Theodore Y. Ts'o <tytso@....edu> wrote:
> 3. You say "not actionable reports without reproducers", but you can
> find hundreds of fixed bugs without reproducers at [1] and [2]. Fix
> ratio for bugs without reproducers is 66% which is not significantly
> lower than 76% for bugs with reproducers. A person without expertise
> in a particular subsystem (me) can't know if a bug is actionable by an
> expert in the subsystem (you) without first reporting this bug.
I think it might be possible to make this a bit easier, without any
manual effort per-bug.
For comparison, when the LKP kernel test robot reports a bug, it
provides a script to reproduce the issue in a VM, such that the
developer need only provide a kernel. The script launches the VM with
the right options, providing a filesystem if necessary, etc.
This is a little more actionale, since the developer need not expend any
effort trying to reproduce the correct envinronment, which can be
especially tricky for bugs that don't have a C reproducer.
Would it be possible for syzbot to do something similar?
Thanks,
Mark.
> [1] https://syzkaller.appspot.com/?fixed=upstream
> [2] https://github.com/google/syzkaller/blob/master/docs/linux/found_bugs.md
Powered by blists - more mailing lists