From: Dmitry Vyukov <firstname.lastname@example.org> To: Linus Torvalds <email@example.com> Cc: "Paolo Bonzini" <firstname.lastname@example.org>, LKML <email@example.com>, "Wanpeng Li" <firstname.lastname@example.org>, "Greg Kroah-Hartman" <email@example.com>, firstname.lastname@example.org, "KVM list" <email@example.com>, "Radim Krčmář" <firstname.lastname@example.org>, "Wei Wu" <email@example.com>, "Kostya Serebryany" <firstname.lastname@example.org>, "Daniel Vetter" <email@example.com>, syzkaller <firstname.lastname@example.org>, "Dan Williams" <email@example.com>, "Chris Mason" <firstname.lastname@example.org>, "Jonathan Corbet" <email@example.com>, "Kees Cook" <firstname.lastname@example.org>, "Laura Abbott" <email@example.com>, "Olof Johansson" <firstname.lastname@example.org>, "Steven Rostedt" <email@example.com>, "Theodore Tso" <firstname.lastname@example.org>, Tim.Bird@sony.com Subject: Re: [PATCH] KVM: X86: Fix scan ioapic use-before-initialization Date: Wed, 9 Jan 2019 09:28:25 +0100 Message-ID: <CACT4Y+biZXfPiU4SPRj=WZAr+J=tazJ7GxxWFce0kO1OPT8hmw@mail.gmail.com> (raw) In-Reply-To: <CACT4Y+Y8pMfxyWgsM2roX8DpDUFMigiR90aY7SMTAQCTcz7SHw@mail.gmail.com> On Wed, Jan 2, 2019 at 3:08 PM Dmitry Vyukov <email@example.com> wrote: > > On Fri, Dec 28, 2018 at 10:09 PM Linus Torvalds > <firstname.lastname@example.org> wrote: > > > > On Fri, Dec 28, 2018 at 1:43 AM Dmitry Vyukov <email@example.com> wrote: > > > > > > > Nobody reads the kernel mailing list directly - there's just too much traffic. > > > > > > As the result bug reports and patches got lots and this is bad and it > > > would be useful to stop it from happening and there are known ways for > > > this. > > > > Well, let me be a bit more specific: you will find that people read > > the very _targeted_ mailing lists, because they not only tend to be > > more specific to some particular interest, but also aren't the flood > > of hundreds of emails a day. > > > > And don't get me wrong: I'm not saying that lkml is useless. Not at > > all. It's just that it's really more of an archival model than a > > "people read it" - so you send your emails to a group of people, and > > then you cc lkml so that when that group gets expanded people can be > > pointed at the whole thread. Or, obviously, so that commit messages > > etc can point to discussion. > > > > But that does mean that any lkml cc shouldn't be expected to cause a > > reaction in itself. It's about other things. > > > > > syzbot not doing bisection is not the root cause of this > > > > Root case? No. But if you do bisection, it means that you can now > > target things much better. So then it's not lkml and "random > > collection of maintainers", but a much more targeted group. > > > > And that targeted group also ends up being a lot more receptive to it. > > > > Again, look at the raw syzbot email and the email by Wanpeng Li. Yes, > > the syzbot email did bring in a reasonable set of people just based on > > the oops (I think it did "get_mainainter" on kvm_ioapic_scan_entry()). > > But Wangpeng ended up sending it to the *particular* people who were > > directly responsible. > > > > > 2. syzbot reports are not worse then average human reports, frequently better. > > > > No, they really aren't. > > > > They are better in a *technical* sense, but they are also very much > > obviously automated, which makes the target people take them much less > > seriously. > > > > When you see lots of syzbot emails, and there are lots of more or less > > random recipients that may or may not be correct, what's the natural > > reaction to that? > > > > Look up "bystander effect". > > > > > 3. Bisection is useful, but not important in most cases. > > > > No. > > > > Exactly because of the problem syzbot has. It's too scatter-shot. > > People clearly ignore it, because people feel it's not _their_ issue. > > > > The advantage of bisection is that it makes the problem much more > > specific. Right now, you'll find that many developers ignore syzbot > > simply because it's not worth their time to chase down whether it's > > even their problem. > > > > See what I'm saying? > > > > It's the whole "data vs information" issue. Particularly when cc'ing > > maintainers, who get hundreds of emails a day, you need to convince > > them that this email is _relevant_. > > I see what you are saying and I agree that bisection results will make > reports better in some cases. But I mean a more general problem. > > Say you reported a bug, and it happened so that you missed that single > right person in CC because something, whatever, can happen, right? > With the current process it will be a coin flip if your report will be > routed to the right person or lost. And it's not that you personally > care a lot about this particular bug, it just happened that you > noticed it and wanted to be a good samaritan. So you will not keep > track of it on a post-note on your monitor and won't ping later. But > the bug can be bad and either cause security problems later, or reach > release and break things in the field and then require 1000x more work > to port the fix to all downstream forks. > > Or, we heavily rely on end users for testing. End users are not kernel > developers and can't be generally expected to do pre-triage and proper > routing. Losing these valuable reports is bad because only small > fraction of users report anything to projects and this can also affect > user trust, if you see that your reports are not acted on, you don't > report next time. > > Even if we take syzbot, it won't be able to bisect all the time for > multiple reasons: > - some bugs don't have reproducers (but still very real and sometimes > manageable to fix) > - kernel is build/boot broken sometimes for prolonged periods > - some old bugs are bisected to introduction of the debugging tool > that detects the bug > - some crashes can be too flaky for reliable bisection > - some reproducers won't work on older kernels, yet the bug is there > - ... > So it's will be nice to have bisection results when they are > available, but it does not feel like it should be the only guarantee > of a bug report not being lost. > > Moreover, you can see in the examples I referenced above that they > were delivered to the right people, but then still lost because there > is nothing in the kernel development process that would prevent loses. > > Moreover, replying on a small set of private emails generally creates > problems wrt bus-factor and vacations. It would be useful if anybody > could see what are the open bugs for rdma_cm subsystem at any point in > time. This is quite indicative: Serious issues affecting all filesystems: Kernel quality control, or the lack thereof https://lwn.net/Articles/774114/ Comment on ycombinator: https://news.ycombinator.com/item?id=18844612 I've filed bugs for some of the mentioned copy_file_range() issues more than two years ago: - https://bugzilla.kernel.org/show_bug.cgi?id=135461 - https://bugzilla.kernel.org/show_bug.cgi?id=135451 No response...
next prev parent 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 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 [this message] 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: 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='CACT4Y+biZXfPiU4SPRj=WZAr+J=tazJ7GxxWFce0kO1OPT8hmw@mail.gmail.com' \ --firstname.lastname@example.org \ --cc=Tim.Bird@sony.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 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/ https://lore.kernel.org/lkml \ email@example.com public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git