LKML Archive on
 help / color / Atom feed
From: Dmitry Vyukov <>
To: Paolo Bonzini <>,
	LKML <>,
	Wanpeng Li <>,
	Linus Torvalds <>,
	Greg Kroah-Hartman <>,
Cc: "KVM list" <>,
	"Radim Krčmář" <>, "Wei Wu" <>,
	"Kostya Serebryany" <>,
	"Daniel Vetter" <>,
	syzkaller <>,
	"Dan Williams" <>,
	"Chris Mason" <>, "Jonathan Corbet" <>,
	"Kees Cook" <>,
	"Laura Abbott" <>,
	"Olof Johansson" <>,
	"Steven Rostedt" <>,
	"Theodore Tso" <>,
Subject: Re: [PATCH] KVM: X86: Fix scan ioapic use-before-initialization
Date: Thu, 27 Dec 2018 15:28:05 +0100
Message-ID: <> (raw)
In-Reply-To: <>

On Sun, Nov 25, 2018 at 6:31 PM Paolo Bonzini <> wrote:
> On 20/11/18 09:34, Wanpeng Li wrote:
> > From: Wanpeng Li <>
> > ...
> > This patch fixes it by bailing out scan ioapic if ioapic is not initialized in
> > kernel.
> > Reported-by: Wei Wu <>

+Linus, Greg

I want to point out that this was reported more then 3 months ago by syzbot:!msg/syzkaller-bugs/cPT7tmaz-gQ/SzOyhM0YBAAJ
then the report was lost on kernel mailing lists and then re-reported
by somebody else:
and only then fixed.

Lots of kernel bug reports routinely get lost on mailing lists, which is bad.

Another bug was reported by syzbot in April:!msg/syzkaller-bugs/-9XIT9gwq7M/sqvBXSZWBgAJ
then get lost and then re-reported in November:
and only then fixed.

Not specific for KVM, another bug in kernel/trace reported by syzbot,
lost for months, then re-reported and fixed:!msg/syzkaller-bugs/o_-OeMyoTwg/Ugh432hlAgAJ

And, no, it's not that people ignore just syzbot reports. It's just
that syzbot reports can be tracked so it's easier to spot such cases,
for manually reported bugs nobody usually knows anything after few
weeks. Here is an example of bug report by a human, which was even
replied but then slipped from somebody's attention set for a moment
and then complete oblivion. Months later happened to be re-reported by
syzbot and then fixed:!msg/syzkaller-bugs/wFUedfOK2Rw/waUrQYOxAQAJ

Re-reported a year later bugs can cause security problems and large
amounts of work to backport the fix to thousands of downstream kernel
forks. Not re-reported bugs are even worse as they are just not fixed.

This Plumbers I was approached by Doug Ledford from Redhat, who said
literally that there was a bunch of syzbot reports in rdma subsystem
but since they were reported some time ago, now nobody knows
what/where are they. So while the bugs are still presumably there, now
they are completely unactionable and kernel development process is
incapable of dealing with this. While syzbot reports have some chances
of being recovered, this equally applies to human-reported bugs and
they can't be easily recovered.

This does not looks like how things should be for the most critical
and fundamental software project in the world. Lost bugs/patches
should not be a thing. There are known working solutions for this in
the form of tooling and procedures, namely bug tracking. Any bug
tracking systems allows to answer the main question: what are the
active bugs, sorted by priority, in subsystem X/assigned to me; and
lots of other useful questions.

And, yes, I know we have bugazilla. But it's not being used as a bug
tracking system as of now. And when used, sometimes cause more trouble
because nobody expects bugs to be there:

  reply index

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-20  8:34 Wanpeng Li
2018-11-25 17:31 ` Paolo Bonzini
2018-12-27 14:28   ` Dmitry Vyukov [this message]
2018-12-27 16:59     ` Linus Torvalds
2018-12-28  9:43       ` Dmitry Vyukov
2018-12-28 21:08         ` Linus Torvalds
2019-01-02 14:08           ` Dmitry Vyukov
2019-01-09  8:28             ` Dmitry Vyukov
2018-12-28 22:13         ` Joey Pabalinas
2019-01-02 13:43           ` Dmitry Vyukov
2019-01-07 23:11       ` Paolo Bonzini

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

LKML Archive on

Archives are clonable:
	git clone --mirror lkml/git/0.git
	git clone --mirror lkml/git/1.git
	git clone --mirror lkml/git/2.git
	git clone --mirror lkml/git/3.git
	git clone --mirror lkml/git/4.git
	git clone --mirror lkml/git/5.git
	git clone --mirror lkml/git/6.git
	git clone --mirror lkml/git/7.git
	git clone --mirror lkml/git/8.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ \
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone