linux-kernel - Re: Subject: [RFC] clang tooling cleanups

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:   Tue, 27 Oct 2020 12:51:57 -0700
From:   Joe Perches <joe@...ches.com>
To:     Tom Rix <trix@...hat.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        linux-toolchains@...r.kernel.org, Julia.Lawall@...6.fr,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Nathan Huckleberry <nhuck15@...il.com>
Subject: Re: Subject: [RFC] clang tooling cleanups

(Adding Stephen Rothwell)

On Tue, 2020-10-27 at 12:33 -0700, Tom Rix wrote:
> On 10/27/20 11:42 AM, Nick Desaulniers wrote:
> > (cutting down the CC list to something more intimate)

[]

> I am interested in treewide fixes.

As am I, but here the definition of fixes is undefined though.
Whitespace / style changes and other bits that don't change generated
object code aren't considered fixes by many maintainers.

> Cleaning them up (maybe me not doing all the patches) and keeping them clean.
> 
> The clang -Wextra-semi-stmt -fixit will fix all 10,000 problems

I rather doubt there are 10K extra semicolons in the kernel source tree.
Is there a proposed diff/patch posted somewhere?

> This clang tidy fixer will fix only the 100 problems that are 'switch() {};'
> 
> When doing a treewide cleanup, batching a bunch of fixes that are the same problem and fix 
> is much easier on everyone to review and more likely to be accepted.

That depends on the definition of batching.

If individual patches are sent to multiple maintainers, the
acceptance / apply rate seems always < 50% and some are rejected
outright by various maintainers as "unnecessary churn".

Single treewide patches are generally not applied unless by Linus.
The trivial tree isn't widely used for this.

Perhaps a 'scripted' git tree could be established that is integrated
into -next that would allow these automated patches to be better
vetted and increase the acceptance rate of these automated patches.

> Long term, a c/i system would keep the tree clean by running the switch-semi checker/fixer. 
> And we can all move onto the next problem.

Good idea...
I hope a scripted patches mechanism will be established.