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

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

[Cihan Karadag]

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.

The warning fires once per patch via a $reported_selftests_gitignore
guard, even when a patch adds several new files under
tools/testing/selftests/ at once, mirroring
$reported_maintainer_file's per patch dedup for FILE_PATH_CHANGES.

Link: https://docs.kernel.org/dev-tools/kselftest.html#contributing-new-tests-details [1]

Signed-off-by: Cihan Karadag <cihan.cihan@gmail.com>
---
 Documentation/dev-tools/checkpatch.rst |  7 +++++++
 scripts/checkpatch.pl                  | 10 ++++++++++
 2 files changed, 17 insertions(+)

diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst
index 6139a08c34cd8..9201d1cda0d44 100644
--- a/Documentation/dev-tools/checkpatch.rst
+++ b/Documentation/dev-tools/checkpatch.rst
@@ -1293,6 +1293,13 @@ Others
   **PRINTF_0XDECIMAL**
     Prefixing 0x with decimal output is defective and should be corrected.
 
+  **SELFTESTS_GITIGNORE**
+    Warn that, if the new file(s) added under tools/testing/selftests/
+    generate any test objects, those objects need to be added to
+    .gitignore.
+
+    See: https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html
+
   **SPDX_LICENSE_TAG**
     The source file is missing or has an improper SPDX identifier tag.
     The Linux kernel requires the precise SPDX identifier in all source files,
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 2b7a42bbdd94f..a4ead4677e3c6 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2701,6 +2701,7 @@ sub process {
 	my $commit_log_long_line = 0;
 	my $commit_log_has_diff = 0;
 	my $reported_maintainer_file = 0;
+	my $reported_selftests_gitignore = 0;
 	my $non_utf8_charset = 0;
 
 	my $last_git_commit_id_linenr = -1;
@@ -3492,6 +3493,15 @@ sub process {
 			     "added, moved or deleted file(s), does MAINTAINERS need updating?\n" . $herecurr);
 		}
 
+# Check for new files added under kselftests
+		if (!$reported_selftests_gitignore && !$in_commit_log &&
+		    ($line =~ /^new file mode\s*\d+\s*$/) &&
+		    ($realfile =~ m@^tools/testing/selftests/@)) {
+			$reported_selftests_gitignore = 1;
+			WARN("SELFTESTS_GITIGNORE",
+			     "Added file(s) under tools/testing/selftests/, if they generate any test objects make sure they are added to .gitignore. See: Documentation/dev-tools/kselftest.rst\n");
+		}
+
 # Check for adding new DT bindings not in schema format
 		if (!$in_commit_log &&
 		    ($line =~ /^new file mode\s*\d+\s*$/) &&
-- 
2.54.0

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

[Jakub Kicinski]

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. In netdev CI at least we build the selftests and check
if there are any untracked files after.

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

[Cihan Karadag]

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.

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

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

[Jakub Kicinski]

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.