On 29/07/2026 10:01, Cihan Karadag wrote: > 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.
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
