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

[Krzysztof Kozlowski <krzk@kernel.org>]

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.

> 
>> In netdev CI at least we build the selftests and check
>> if there are any untracked files after.
> 
> That is a good practice. But as evidenced by commits already in the
> tree, this type of coverage does not exist in all places.
> 
> Since this is a mistake that is frequently made, I think it deserves

You did not prove that.

> a warning on its own. In the end I think it is acceptable that this
> warning fires more than necessary, the same way FILE_PATH_CHANGES

No, it is not acceptable.

> does, because the cost of an extra check is low and the mistakes it
> warns about are easy to miss.


Best regards,
Krzysztof