Re: [PATCH] checkpatch: warn about possible missing gitignore coverage in selftests

[Jeff Johnson <jeff.johnson@oss.qualcomm.com>]

On 7/30/2026 11:26 PM, Krzysztof Kozlowski wrote:
> On 29/07/2026 10:01, Cihan Karadag wrote:
>> On Tue, Jul 28, 2026 at 8:31 AM Jakub Kicinski <kuba@kernel.org> wrote:
>>>
>>> On Mon, 27 Jul 2026 23:24:41 -0600 Cihan Karadag wrote:
>>>> Per selftests documentation [1], every generated test binary must be
>>>> added to gitignore to prevent leaving untracked files in the kernel
>>>> tree.
>>>>
>>>> This is an easy mistake to make when adding a new test. In fact, a
>>>> search of selftests history turns up dozens of standalone follow-up
>>>> patches with titles like "add missing gitignore for <binary>", each
>>>> needed only because the original patch adding a new test
>>>> didn't also update gitignore.
>>>>
>>>> Add a SELFTESTS_GITIGNORE check that warns about gitignore coverage
>>>> whenever a patch adds a new file under tools/testing/selftests/, the
>>>> same way FILE_PATH_CHANGES warns about MAINTAINERS on any added,
>>>> moved, or deleted file.
>>>
>>> What percentage of changes to selftests from last 2 releases will
>>> false-positive trigger this? Would be good to know, checkpatch has
>>> a tendency of generating false positives which is quite counter
>>> productive.
>>
>> It will trigger whenever a new file is added to selftests, which has
>> a chance of introducing a test artifact into the tree. I checked the
>> last 20 commits touching selftests and only 6 of them were new file
>> additions, so this warning would have fired 6 times. Actually, one of
>> those 6 had a missing gitignore entry that this check is supposed to
>> warn about (fuse_acl_cache_test, 9acb102522b9).
>>
>> Comparing to other WARNINGs that checkpatch generates, such as
>> FILE_PATH_CHANGES which has existed since 2014, this seems like a
>> reasonable and already accepted way for checkpatch to operate.
>>
>> For comparison, I checked the last 20 commits that triggered
>> FILE_PATH_CHANGES in the tree, and none of them actually needed a
>> MAINTAINERS update.
> 
> FILE_PATH_CHANGES causes many false-positives, honestly for my work of
> getting 100-200 commits per release it was screaming like 20% of time
> and never had it right. All of its reports are false positives to me.
> 
> And I saw many times people do weird commits and weird MAINTAINERS
> updates, just because checkpatch asked them.
> 
> So your argument of "reasonable and already accepted way for checkpatch
> to operate" is simply wrong. Don't add more poor tests jut because we
> have one which is IMO terrible.

Concur.
In my tooling I always set:
--ignore COMMIT_LOG_LONG_LINE,FILE_PATH_CHANGES

/jeff