linux-kernel - Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support multiple checkers

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1515181301.31439.724.camel@oracle.com>
Date:   Fri, 05 Jan 2018 20:41:41 +0100
From:   Knut Omang <knut.omang@...cle.com>
To:     Mauro Carvalho Chehab <mchehab@...nel.org>
Cc:     Jani Nikula <jani.nikula@...ux.intel.com>,
        linux-kernel@...r.kernel.org,
        Nicolas Palix <nicolas.palix@...g.fr>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        John Haxby <john.haxby@...cle.com>, linux-doc@...r.kernel.org,
        Jonathan Corbet <corbet@....net>,
        Gilles Muller <Gilles.Muller@...6.fr>,
        Michal Marek <michal.lkml@...kovi.net>,
        Mickaël Salaün <mic@...ikod.net>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        Julia Lawall <Julia.Lawall@...6.fr>,
        Håkon Bugge <haakon.bugge@...cle.com>,
        Åsmund Østvold <asmund.ostvold@...cle.com>,
        Matthew Wilcox <willy@...radead.org>,
        "Levin, Alexander (Sasha Levin)" <alexander.levin@...izon.com>,
        cocci@...teme.lip6.fr, linux-kbuild@...r.kernel.org
Subject: Re: [PATCH v3 1/1] runchecks: Generalize make C={1,2} to support
 multiple checkers

On Fri, 2018-01-05 at 16:08 -0200, Mauro Carvalho Chehab wrote:
> Em Thu, 04 Jan 2018 21:15:31 +0100
> Knut Omang <knut.omang@...cle.com> escreveu:
> 
> > > I'm surprised the commit message and the provided documentation say
> > > nothing about using CHECK=foo on the command line. That already supports
> > > arbitrary checkers.   
> > 
> > The problem, highlighted by Jim Davis in
> > 
> > https://lkml.org/lkml/2017/11/20/638
> > 
> > is that the current solution isn't flexible enough - that discussion 
> > is what lead me to this reimplementation of what I originally intended 
> > to be a checkpatch only solution.
> > 
> > > How does this relate to that? Is this supposed to be
> > > a complete replacement? Or what?  
> > 
> > It has evolved into a complete replacement of the intention of CHECK.
> > 
> > > 'make help' also references $CHECK, and this patch doesn't update the
> > > help text.  
> > 
> > I realize now that this needs to be handled in some way due to the way I split the 
> > arguments with '--' - the intention was to keep it for bw compatibility.
> > 
> > It would be good to know if people rely on using CHECK with C={1,2} for 
> > anything beside the checkers supported by runchecks today
> 
> I do. Here, I use:
> 
> $ make ARCH=i386  CF=-D__CHECK_ENDIAN__ CONFIG_DEBUG_SECTION_MISMATCH=y C=1 W=1
> CHECK='compile_checks' M=drivers/media
> 
> Where "compile_checks" is actually a small script that calls both
> smatch and sparse:
> 
> 	#!/bin/bash
> 	/devel/smatch/smatch -p=kernel $@

I suppose you here refer to this:
https://blogs.oracle.com/linuxkernel/smatch-static-analysis-tool-overview,-by-dan-carpenter

Good idea! I'll have a look at how that plays with this.

> 	/devel/sparse/sparse $@
> 
> So, I'm not sure why we need something else. 

The core functionality is the selective suppression logic and output unification
which makes checking with automated build tools more flexible and 
applicable right away (not when every warning from every checker is fixed...)

> That said, I didn't look
> on its code, but looking on its diffstat:
> 
>  Makefile                               |  23 +-
>  scripts/Makefile.build                 |   4 +-
>  scripts/runchecks                      | 734 ++++++++++++++++++++++++++-
>  scripts/runchecks.cfg                  |  63 ++-
>  scripts/runchecks_help.txt             |  43 ++-
> 
> Using a 734 lines python program just to do an exec on an external checker
> seems too much!

Sure, if that was the case I would be the first to agree :-)

Thanks,
Knut

> Thanks,
> Mauro