On 7/30/2026 11:26 PM, Krzysztof Kozlowski wrote: > 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.
Concur. In my tooling I always set: --ignore COMMIT_LOG_LONG_LINE,FILE_PATH_CHANGES /jeff
