From: Steven Rostedt <rostedt@goodmis.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andy Whitcroft <apw@shadowen.org>, Dave Jones <davej@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] checkpatch: Test for kmalloc/memset(0) pairs
Date: Thu, 17 Mar 2011 23:32:50 -0400 [thread overview]
Message-ID: <1300419170.16880.956.camel@gandalf.stny.rr.com> (raw)
In-Reply-To: <20110317211548.646b04d2@tpl.lwn.net>
On Thu, 2011-03-17 at 21:15 -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?
>
Hmm, to me Coccinelle is sorta the big hammer approach to this. It can
be used to analyze the kernel code that exists. checkpatch is made to
stop developers from adding new crap.
That said, I wonder if there is a way to make one use information from
the other. Perhaps we can make checkpatch read the Concinelle rules.
Honestly, I've never used Concinelle and have no idea how to use it.
Looking at their web site there's a PDF on how to use something called
"spatch" but it seems more complex than checkpatch.
But if we can teach checkpatch to read the rule files, then maybe that
would be beneficial.
-- Steve
next prev parent reply other threads:[~2011-03-18 3:32 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 [this message]
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
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=1300419170.16880.956.camel@gandalf.stny.rr.com \
--to=rostedt@goodmis.org \
--cc=akpm@linux-foundation.org \
--cc=apw@shadowen.org \
--cc=corbet@lwn.net \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.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;
as well as URLs for NNTP newsgroup(s).