ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Roland Dreier <roland@kernel.org>
Cc: "ksummit-discuss@lists.linuxfoundation.org"
	<ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] coverity, static checking etc.
Date: Fri, 9 May 2014 16:52:13 -0400	[thread overview]
Message-ID: <20140509205213.GA21354@redhat.com> (raw)
In-Reply-To: <CAG4TOxONfcd=c+78yxUVj4iOQ_n7+RShPeir9HWUQ_zGDWYJig@mail.gmail.com>

On Fri, May 09, 2014 at 01:33:46PM -0700, Roland Dreier wrote:
 > On Fri, May 9, 2014 at 10:07 AM, Dave Jones <davej@redhat.com> wrote:
 > > Last year I had been doing the coverity scans on an almost daily basis
 > > for 2-3 months.  Now that we're a year in, I'd like to share some
 > > results, and show some of the more common trends and bug patterns that
 > > seem to pop up.
 > 
 > This probably doesn't add too much to the discussion, but as a
 > subsystem maintainer, I like having easy-to-run analysis tools (or
 > easily available scan results like coverity).  It seems to lead to
 > interesting patches from people who aren't really interested in the
 > subsystem but just trawl through scan results.
 > 
 > It's pretty cool getting fixes for subtle (but in retrospect obvious)
 > bugs from people who say "compile tested only because I have no
 > hardware."

I've been apprehensive about approving some of the people signing up
for coverity. There's been a large influx of people over the last few
months whose only prior kernel commits have been things like checkpatch
fixes. On one hand, it's great to see people wanting to progress beyond
that, but I know some maintainers have had a less than positive reaction
with getting crap patches based on coverity results. It's a tricky
balance, but I think for the most part my judgment is erring on the
right side of the approve/deny fence.

The one thing I can't wait for Coverity to implement is the ability
to say "bugs for this subsystem go to this mailing list".  At that point
the mails it sends out should be a lot more useful, and maintainers
themselves will be able to take action. (I know some people hate the
web UI, so this will hopefully appease them).

Most people have got a lot better at jumping on things as they get
introduced, which is great.  The stuff that sucks is the old reports
that have been in their database forever.  I've (along with several
other people) been periodically going through these trying to weed
out the real bugs from the false positive/intentionals.

I'll need to come up with some way to periodically send a bunch of
those to lists too.

	Dave

  reply	other threads:[~2014-05-09 20:52 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-09 17:07 Dave Jones
2014-05-09 17:19 ` josh
2014-05-09 17:31   ` Johannes Berg
2014-05-09 17:54     ` Guenter Roeck
2014-05-09 18:04     ` Mark Brown
2014-05-09 19:08     ` Jiri Kosina
2014-05-09 19:41       ` Dmitry Torokhov
2014-05-09 19:29     ` Josh Triplett
2014-05-09 17:37 ` Bjorn Helgaas
2014-05-09 20:18 ` Arnd Bergmann
2014-05-09 20:33   ` Dave Jones
2014-05-09 21:39     ` Arnd Bergmann
2014-05-09 20:33 ` Roland Dreier
2014-05-09 20:52   ` Dave Jones [this message]
2014-05-09 20:57 ` tytso
2014-05-14 11:06   ` Dan Carpenter
2014-05-11 11:10 ` Wolfram Sang
2014-05-12  6:48   ` Michal Simek
2014-05-12  9:32     ` Wolfram Sang
2014-05-14 11:09       ` Dan Carpenter
2014-05-14 13:32       ` Johannes Berg
2014-05-14 13:51         ` Guenter Roeck
2014-05-14 15:22           ` Wolfram Sang
2014-05-14 15:44             ` Peter Huewe
2014-05-14 16:36               ` Wolfram Sang
2014-05-18 16:38     ` Mauro Carvalho Chehab
2014-05-19 10:13       ` Michal Simek
2014-05-12  8:58   ` Peter Senna Tschudin

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=20140509205213.GA21354@redhat.com \
    --to=davej@redhat.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=roland@kernel.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox