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.
