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

On Tue, Jul 28, 2026 at 8:31 AM Jakub Kicinski <[email protected]> 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.

> 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
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
does, because the cost of an extra check is low and the mistakes it
warns about are easy to miss.