linux-kernel - Re: [PATCH v3] checkpatch: fix false positives in REPEATED

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: <b2532a0a0032d39657a46198bf572a53232d29a4.camel@perches.com>
Date:   Fri, 23 Oct 2020 13:19:05 -0700
From:   Joe Perches <joe@...ches.com>
To:     Lukas Bulwahn <lukas.bulwahn@...il.com>,
        Aditya Srivastava <yashsri421@...il.com>
Cc:     linux-kernel@...r.kernel.org,
        linux-kernel-mentees@...ts.linuxfoundation.org,
        dwaipayanray1@...il.com
Subject: Re: [PATCH v3] checkpatch: fix false positives in REPEATED_WORD
 warning

On Fri, 2020-10-23 at 21:06 +0200, Lukas Bulwahn wrote:
> On Fri, 23 Oct 2020, Aditya Srivastava wrote:
> > A quick evaluation on v5.6..v5.8 showed that this fix reduces
> > REPEATED_WORD warnings from 2797 to 907.
> > 
> > A quick manual check found all cases are related to hex output or
> > list command outputs in commit messages.
[] 
> I think this strategy now makes sense and has the right complexity for a 
> good heuristics in this case.

The proper indentation was not followed as described in a previous reply.
This patch also causes conflicts with Dwaipayan's earlier effort.

Lastly, I'm not sure this complexity is worthwhile.

The style is also somewhat complex and doesn't allow for upper and lower
case variants.

I still think that a trivial "is $first hex only" test is simpler.

Perhaps use a hash and an exists test if this is useful at all.

What specific matches were found with this word list?
Why not just add those to the word list?

In all the nearly 1 million commit descriptions in the kernel without
the patch contexts, these were the only hex-like word matches I found
with their count of matches:

76 be
17 Add
13 add
6 dada
2 Bad
2 bad

100 or so false positives in about a million commits isn't many.

dada is not an actual word in a commit message so I suggest
adding hex word like checks only for "be" "add" and "bad".

Maybe "added" too but that hasn't been used as far as I can tell.

But all the other dictionary entries don't appear to be useful.

So maybe something like:

our %allow_repeated_words = (
	add => '',
	added => '',
	bad => '',
	be => '',
);

and

	next if (exists($allow_repeated_words{lc($first)}));