linux-kernel - Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program

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]

Date:   Mon, 18 Dec 2017 14:41:23 +0100
From:   Knut Omang <knut.omang@...cle.com>
To:     Jason Gunthorpe <jgg@...pe.ca>
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        linux-kernel@...r.kernel.org,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Nicolas Palix <nicolas.palix@...g.fr>,
        Jonathan Corbet <corbet@....net>,
        Santosh Shilimkar <santosh.shilimkar@...cle.com>,
        Matthew Wilcox <willy@...radead.org>, cocci@...teme.lip6.fr,
        rds-devel@....oracle.com, linux-rdma@...r.kernel.org,
        linux-doc@...r.kernel.org, Doug Ledford <dledford@...hat.com>,
        Mickaël Salaün <mic@...ikod.net>,
        Shuah Khan <shuah@...nel.org>, linux-kbuild@...r.kernel.org,
        Michal Marek <michal.lkml@...kovi.net>,
        Julia Lawall <Julia.Lawall@...6.fr>,
        John Haxby <john.haxby@...cle.com>,
        Åsmund Østvold <asmund.ostvold@...cle.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Kees Cook <keescook@...omium.org>, netdev@...r.kernel.org,
        Gilles Muller <Gilles.Muller@...6.fr>,
        "David S. Miller" <davem@...emloft.net>,
        Joe Perches <joe@...ches.com>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        Håkon Bugge <haakon.bugge@...cle.com>,
        Andy Whitcroft <apw@...onical.com>,
        "Levin, Alexander (Sasha Levin)" <alexander.levin@...izon.com>
Subject: Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via
 a wrapper program

On Sun, 2017-12-17 at 22:00 -0700, Jason Gunthorpe wrote:
> On Sun, Dec 17, 2017 at 03:14:10AM +0100, Knut Omang wrote:
> 
> > > I like the ability to add more checkers and keep then in the main
> > > upstream tree. But adding overrides for specific subsystems goes against
> > > the policy that all subsystems should be treated equally.
> > 
> > This is a tool to enable automated testing for as many checks as
> > possible, as soon as possible. Like any tool, it can be misused, but
> > that's IMHO an orthogonal problem that I think the maintainers will
> > be more than capable of preventing.
> > 
> > Think of this as a tightening screw: We eliminate errors class by
> > class or file by file, and in the same commit narrows in the list of
> > exceptions. That way we can fix issues piece by piece while avoiding
> > a lot of regressions in already clean parts.
> 
> Since you used drivers/infiniband as an example for this script..
> 
> I will say I agree with this idea.

> It is not that we *want* infiniband to be different from the rest of
> the kernel, it is that we have this historical situation where we
> don't have a code base that already passes the various static checker
> things.

I poked around trying make M= in different parts of the kernel to get some 
"mileage" and to get as much examples as possible, and it appears most of 
the kernel has issues of sorts. Also Joe and others keep adding more checks 
as well, and we'd want that process to coexist with the need for automatic 
regression testing in this area.

> I would like it very much if I could run 'make static checker' and see
> no warnings. 

which is just what is the result with 'make C=2 M=drivers/infiniband/core' 
and the patches #1 and #5 in this set in case not everyone got the point,

> This helps me know that I when I accept patches I am not
> introducing new problems to code that has already been cleaned up.
> 
> Today when we run checkers we get so many warnings it is too hard to
> make any sense of it.
> 
> Being able to say File X is now clean for check XYZ seems very useful
> and may motivate people to clean up the files they actualy care
> about...
> 
> > > There was discussion at Kernel Summit about how the different
> > > subsystems already have different rules. This appears to be a way
> > > to make that worse.
> > 
> > IMHO this is a tool that should help maintainers implement the
> > policies they desire.  But the tool itself does not dictate any
> > such.
> 
> Yes, again, in infiniband we like to see checkpatch be good for new
> submission, even if that clashes with surrounding code. For instance
> we have a mixture of sizeof foo and sizeof(foo) styles in the same
> file/function now.

That's one of the fixes that the excellent --fix-inplace handles so 
one of my patches here

https://github.com/torvalds/linux/compare/master...knuto:runchecks

fixes those in drivers/infiniband/core.

> I certainly don't want to tell people they need to follow some
> different style from 10 years ago when they send patches.
> 

Thanks,
Knut

> Jason