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, 23 Oct 2023 07:52:21 -0700
From: Jakub Kicinski <>
To: Philip Li <>
Cc: "Nambiar, Amritha" <>,
 <>, kernel test robot <>,
 <>, <>
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:
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

> 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) :(

Powered by blists - more mailing lists