netdev - Re: [net-next PATCH v5 01/10] netdev-genl: spec: Extend netdev netlink spec in YAML for queue

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: <20231023075221.0b873800@kernel.org>
Date: Mon, 23 Oct 2023 07:52:21 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Philip Li <philip.li@...el.com>
Cc: "Nambiar, Amritha" <amritha.nambiar@...el.com>,
 <oe-kbuild-all@...ts.linux.dev>, kernel test robot <lkp@...el.com>,
 <netdev@...r.kernel.org>, <pabeni@...hat.com>
Subject: Re: [net-next PATCH v5 01/10] netdev-genl: spec: Extend netdev
 netlink spec in YAML for queue

On Sat, 21 Oct 2023 09:53:03 +0800 Philip Li wrote:
> > Some of them are bogus. TBH I'm not sure how much value running
> > checkpatch in the bot adds. It's really trivial to run for the  
> 
> It is found there're quite some checkpatch related fix commits on
> mainline.

Those changes are mostly for old code, aren't they?
It'd be useful to do some analysis of how long ago the mis-formatted
code has been introduced. Because if new code doesn't get fixes
there's no point testing new patches..

> Thus the bot wants to extend the coverage and do shift
> left testing on developer repos and mailing list patches.

I understand and appreciate the effort. 

I think that false positive has about a 100x the negative effect of a
true positive. If more than 1% of checkpatch warnings are ignored, we
should *not* report them to the list. Currently in networking we fully
trust the build bot and as soon as a patch set gets a reply from you it
gets auto-dropped from our review queue.
It'd be quite bad if we have to double check the reports.

Speaking of false positive rate - we disabled some checks in our own
use of checkpatch:
https://github.com/kuba-moo/nipa/blob/master/tests/patch/checkpatch/checkpatch.sh#L6-L12
and we still get about 26% false positive rate! (Count by looking at
checks that failed and were ignored, because patch was merged anyway).
A lot of those may be line length related (we still prefer 80 char
limit) but even without that - checkpatch false positives a lot.

And the maintainer is not very receptive to improvements for false
positives:
https://lore.kernel.org/all/20231013172739.1113964-1-kuba@kernel.org/

> But as you mentioned above, we will take furture care to the output
> of checkpatch to be conservative for the reporting.

FWIW the most issues that "get through" in networking are issues 
in documentation (warnings for make htmldocs) :(