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

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 29 Jul 2026 02:01:48 -0600 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.

Exactly, we have some experience with these useless checks.
Let's not add more low effort stuff.

> > 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.

Could you explain your involvement in kernel development?
It would help us understand where you're coming from.

> 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.

You assume people who don't bother testing the code they merge 
(or write) will bother to run checkpatch. Not sure that's true.

The problems I see are that - (1) adding false positives makes
people accustomed to ignoring checkpatch warnings in general.

(2) We'd make life harder for people who do automated code
validation (by adding false positives they have to track / 
add exceptions for). We should be moving more towards automation
as a community. Time for questionable pattern matching with
Perl has passed.