linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Jones <davej@redhat.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Steven Rostedt <rostedt@goodmis.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Andy Whitcroft <apw@shadowen.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] checkpatch: Test for kmalloc/memset(0) pairs
Date: Sat, 19 Mar 2011 15:39:55 -0400	[thread overview]
Message-ID: <20110319193954.GA2032@redhat.com> (raw)
In-Reply-To: <20110317211548.646b04d2@tpl.lwn.net>

On Thu, Mar 17, 2011 at 09:15:48PM -0600, Jonathan Corbet wrote:
 > On Thu, 17 Mar 2011 22:52:24 -0400
 > Steven Rostedt <rostedt@goodmis.org> wrote:
 > 
 > > The use of kzalloc() is preferred over kmalloc/memset(0) pairs.
 > > 
 > > When a match is made with "memset(p, 0, s);" a search back through the
 > > patch hunk is made looking for "p = kmalloc(s,". If that is found, then
 > > a warning is given, suggesting to use kzalloc() instead.
 > 
 > The Coccinelle stuff already has a lot of this kind of test.  See, for
 > example, scripts/coccinelle/api/alloc/kzalloc-simple.cocci.  Suppose
 > there is some way all this nice analysis infrastructure could be
 > integrated instead of duplicated?  Or am I just a crazy dreamer?

Maybe.  Coccinelle is one of those tools that seems to be perpetually
on my "to look into" list that I never get around to.


Something that has crossed my mind over the last few days was the idea
of splitting checkpatch into two tools.
One for checking CodingStyle issues, and one for checking for actual
code problems like the memset example.

The motivation for such is that I think it's pretty clear that many maintainers
never run checkpatch on patches they queue up before pushing to Linus...

$ scripts/checkpatch.pl  ~/Mail/upstream/2.6.39/head-March-18-2011 | wc -l
2361

The bulk of this is all "missing space here" "don't put a space there" type
fluff that most maintainers just don't care about.  Any valuable warnings
are lost in the noise.  If we had a separate tool to check for real flaws,
(or even a way to suppress the stylistic warnings from the existing one)
maybe more maintainers would run their changes through it.

I dunno, maybe I'm just a crazy dreamer too, but I think many people
have written checkpatch off as useless in its current incarnation.

	Dave


  parent reply	other threads:[~2011-03-19 19:40 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-18  2:52 [PATCH] checkpatch: Test for kmalloc/memset(0) pairs Steven Rostedt
2011-03-18  3:15 ` Jonathan Corbet
2011-03-18  3:32   ` Steven Rostedt
2011-03-20  3:40     ` Américo Wang
2011-03-20  7:02       ` Pekka Enberg
2011-03-20  8:01         ` Julia Lawall
2011-03-20  9:02           ` Pekka Enberg
2011-03-20  9:17             ` Julia Lawall
2011-03-20 10:54               ` Ingo Molnar
2011-03-20 11:06                 ` Pekka Enberg
2011-03-20 11:32                   ` Nicolas Palix
2011-03-20 12:00                     ` Julia Lawall
2011-03-20 11:09                 ` Alexey Dobriyan
2011-03-20 12:38                 ` Julia Lawall
2011-03-20 14:48                 ` Alejandro Riveira Fernández
2011-03-21 13:13                   ` Steven Rostedt
2011-03-24 15:34               ` Aneesh Kumar K. V
2011-03-24 16:08                 ` Julia Lawall
2011-03-24 16:10                   ` Nicolas Palix
2011-03-24 18:30                     ` Arnaud Lacombe
2011-03-24 20:39                       ` Julia Lawall
2011-03-24 17:28                   ` Aneesh Kumar K. V
2011-03-19 19:39   ` Dave Jones [this message]
2011-03-21 13:26     ` Steven Rostedt
2011-03-21 13:29       ` Steven Rostedt
2011-03-21 13:55       ` Borislav Petkov
2011-03-22 19:58       ` checkpatch: introduce --nocs to disable CodingStyle warnings Dave Jones
2011-03-22 20:21         ` Joe Perches

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=20110319193954.GA2032@redhat.com \
    --to=davej@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=apw@shadowen.org \
    --cc=corbet@lwn.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rostedt@goodmis.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;
as well as URLs for NNTP newsgroup(s).