linux-kernel - Re: [PATCH 3/5] checkpatch: add a blacklist

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 30 Sep 2009 16:27:08 +0100
From:	Andy Whitcroft <apw@...onical.com>
To:	Li Zefan <lizf@...fujitsu.com>
Cc:	Daniel Walker <dwalker@...o99.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH 3/5] checkpatch: add a blacklist

On Tue, Sep 22, 2009 at 02:29:37PM +0800, Li Zefan wrote:
> Daniel Walker wrote:
> > There are times when maintainers intentially don't follow the coding
> > style. When that happens it means some errors need to be ignored, so
> > that other errors can be focused on.
> > 
> > To handle that I added a blacklist to checkpatch. The blacklist holds the
> > file names and errors which are ignored. The output is modified to
> > remove the errors from the list and not to count them.
> > 
> > When the blacklist kicks in there is a note that does list how many
> > errors got removed and that it was due to a blacklist entry. There is
> > also a new option "--noblacklist" that allows the errors to be added
> > back as it was without the blacklist.
> > 
> 
> So, for this piece of code:
> 
> TRACE_EVENT(...
> 
> 	TP_fast_assign(
> 		__entry->foo = bar( xxx );
> 	),
> )
> 
> checkpatch won't report the spaces inside bar()?
> If so, I don't like this patch.
> 
> Could you just teach checkpatch to recognize those macros used
> in TRACE_EVENT(), if those coding-style "errors" bother you
> so much that you can't put up with them?


Yeah I think that blanket ignoring spacing throughout the file seems
dangerous.  If these are going to show up a lot then it seems more sensible
to special case TRACE_EVENT or whatever is triggering the actual 'false'
matches.  I also suspect the 'this should never get long' argument will
not be true.  Once you can have an exception people will add them all over

Care to share an example of a change which is triggereing so we can
better target the exception.

-apw
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/