Move Rust linting logic into scripts/rust_checkpatch.pl to prevent
further growth of the main checkpatch.pl script.

Warn against the use of .unwrap() and .expect() unless accompanied by
a '// PANIC:' comment. This enforces safety standards in the Rust-
for-Linux project until upstream Clippy lints are integrated.

Suggested-by: Joe Perches <joe@perches.com>
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Link: https://github.com/Rust-for-linux/linux/issues/1191
Signed-off-by: Jason Hall <jason.kei.hall@gmail.com>

---
v5:
 - Move Rust-specific logic to scripts/rust_checkpatch.pl (Suggested by Joe Perches).
 - Add conditional loading hook in scripts/checkpatch.pl.
 - Updated regex to use house-style comments.
v4:
 - Use imperative mood in commit description.
 - Fix patch formatting and placement of '---' separator.
v3:
 - Use non-capturing groups (?:) to optimize regex.
v2:
 - Switch from \b to (\.|::) to avoid false positives in strings.
 - Add : to PANIC comment check.
---
 scripts/checkpatch.pl      | 14 ++++++++++++++
 scripts/rust_checkpatch.pl | 25 +++++++++++++++++++++++++
 2 files changed, 39 insertions(+)
 create mode 100644 scripts/rust_checkpatch.pl

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index c0250244cf7a..f75cb70ad0dd 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -20,6 +20,12 @@ my $D = dirname(abs_path($P));
 
 my $V = '0.32';
 
+my $rust_checkpatch_available = 0;
+if (-e "$D/rust_checkpatch.pl") {
+	require "$D/rust_checkpatch.pl";
+	$rust_checkpatch_available = 1;
+}
+
 use Getopt::Long qw(:config no_auto_abbrev);
 
 my $quiet = 0;
@@ -2947,6 +2953,14 @@ sub process {
 
 		$cnt_lines++ if ($realcnt != 0);
 
+# Check for Rust-specific lints
+		if ($rust_checkpatch_available && $realfile =~ /\.rs$/) {
+			my ($type, $msg) = process_rust($line, $rawline, $herecurr);
+			if ($type) {
+				WARN($type, $msg);
+			}
+		}
+
 # Verify the existence of a commit log if appropriate
 # 2 is used because a $signature is counted in $commit_log_lines
 		if ($in_commit_log) {
diff --git a/scripts/rust_checkpatch.pl b/scripts/rust_checkpatch.pl
new file mode 100644
index 000000000000..69db5ded7371
--- /dev/null
+++ b/scripts/rust_checkpatch.pl
@@ -0,0 +1,25 @@
+#!/usr/bin/env perl
+# SPDX-License-Identifier: GPL-2.0
+#
+# (c) 2026, Jason K. Hall <jason.kei.hall@gmail.com>
+
+use strict;
+use warnings;
+
+sub process_rust {
+    my ($line, $rawline, $herecurr) = @_;
+
+    # check for Rust unwrap/expect
+    if ($line =~ /^\+/) {
+        if ($line =~ /(?:\.|::)(?:unwrap|expect)\s*\(/ &&
+            $rawline !~ /\/\/\s*PANIC:/ &&
+            $line !~ /^\+\s*\/\// &&
+            $line !~ /^\+\s*assert/) {
+            return ("RUST_UNWRAP",
+                    "Avoid unwrap() or expect() in Rust code; use proper error handling (Result) or justify with a '// PANIC: ...' comment.\n" . $herecurr);
+        }
+    }
+    return ();
+}
+
+1;
\ No newline at end of file
-- 
2.43.0

On Thu, Feb 5, 2026 at 2:42 AM Jason Hall <jason.kei.hall@gmail.com> wrote:
>
> Move Rust linting logic into scripts/rust_checkpatch.pl to prevent
> further growth of the main checkpatch.pl script.
>
> Warn against the use of .unwrap() and .expect() unless accompanied by
> a '// PANIC:' comment. This enforces safety standards in the Rust-
> for-Linux project until upstream Clippy lints are integrated.
>
> Suggested-by: Joe Perches <joe@perches.com>
> Suggested-by: Miguel Ojeda <ojeda@kernel.org>
> Link: https://github.com/Rust-for-linux/linux/issues/1191
> Signed-off-by: Jason Hall <jason.kei.hall@gmail.com>

Ideally, this would be two patches -- one performing the move and the
other adding the new lint.

Either way, the file should be added to `MAINTAINERS` -- not sure if
Joe would want to maintain it or perhaps have a new sub-entry or
perhaps a co-maintainer etc.

> +                    "Avoid unwrap() or expect() in Rust code; use proper error handling (Result) or justify with a '// PANIC: ...' comment.\n" . $herecurr);

By "proper error handling", I guess you mean bubbling the error up
with `?` or similar, right?

There are also other options, like using `unsafe` sometimes etc.

I think perhaps the best is to keep the message a bit less strict
(since there are cases where it is OK) and put the details in a link
to, say, https://rust.docs.kernel.org/kernel/error/type.Result.html#error-codes-in-c-and-rust
(Cc'ing Dirk who was involved in that).

I am thinking of something like:

    `unwrap()` and `expect()` should generally be avoided in Rust
kernel code modulo some exceptions (e.g. within asserts in doctests).
If the use is intended, then please justify it with a `// PANIC:`
comment. Please see ...

But I will let others comment...

(Also, please Cc all the maintainers/reviews of Rust and checkpatch --
doing so here).

Thanks!

Cheers,
Miguel

On 05.02.2026 21:55, Miguel Ojeda wrote:
> On Thu, Feb 5, 2026 at 2:42 AM Jason Hall <jason.kei.hall@gmail.com> wrote:
>>
>> Move Rust linting logic into scripts/rust_checkpatch.pl to prevent
>> further growth of the main checkpatch.pl script.
>>
>> Warn against the use of .unwrap() and .expect() unless accompanied by
>> a '// PANIC:' comment. This enforces safety standards in the Rust-
>> for-Linux project until upstream Clippy lints are integrated.
>>
>> Suggested-by: Joe Perches <joe@perches.com>
>> Suggested-by: Miguel Ojeda <ojeda@kernel.org>
>> Link: https://github.com/Rust-for-linux/linux/issues/1191
>> Signed-off-by: Jason Hall <jason.kei.hall@gmail.com>
> 
> Ideally, this would be two patches -- one performing the move and the
> other adding the new lint.
> 
> Either way, the file should be added to `MAINTAINERS` -- not sure if
> Joe would want to maintain it or perhaps have a new sub-entry or
> perhaps a co-maintainer etc.
> 
>> +                    "Avoid unwrap() or expect() in Rust code; use proper error handling (Result) or justify with a '// PANIC: ...' comment.\n" . $herecurr);
> 
> By "proper error handling", I guess you mean bubbling the error up
> with `?` or similar, right?
> 
> There are also other options, like using `unsafe` sometimes etc.
> 
> I think perhaps the best is to keep the message a bit less strict
> (since there are cases where it is OK) and put the details in a link
> to, say, https://rust.docs.kernel.org/kernel/error/type.Result.html#error-codes-in-c-and-rust
> (Cc'ing Dirk who was involved in that).
> 
> I am thinking of something like:
> 
>      `unwrap()` and `expect()` should generally be avoided in Rust


Gary had some concerns about `expect()` in

https://lore.kernel.org/rust-for-linux/DG3VYAW3TXEO.1YG8N99YWCDR6@garyguo.net/


> kernel code modulo some exceptions (e.g. within asserts in doctests

... and `tests`)

? See

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/rust/kernel/alloc/kvec.rs?h=v6.19-rc8#n1355

).
> If the use is intended, then please justify it with a `// PANIC:`
> comment. Please see ...


I'm totally fine with this. In consequence do we agree that this will 
result in some follow up patches annotating the existing "allowed" 
exceptional / intended cases (e.g. in doctests and tests) with `// 
PANIC:` comments?

Best regards

Dirk



> But I will let others comment...
> 
> (Also, please Cc all the maintainers/reviews of Rust and checkpatch --
> doing so here).
> 
> Thanks!
> 
> Cheers,
> Miguel

On Fri, Feb 6, 2026 at 9:32 AM Dirk Behme <dirk.behme@de.bosch.com> wrote:
>
> Gary had some concerns about `expect()` in

Yeah, for `expect()` in `checkpatch.pl`, the current message does not
make much sense, i.e. perhaps we want a slightly different one,
without the `// PANIC` bit.

Or perhaps, like Gary says, we don't warn for that one, at least for
now. I think we discussed pros/cons of using `expect()` to begin with
recently -- Gary?

> I'm totally fine with this. In consequence do we agree that this will
> result in some follow up patches annotating the existing "allowed"
> exceptional / intended cases (e.g. in doctests and tests) with `//
> PANIC:` comments?

Those are the ones that would not need annotations, i.e. they would be
false positives.

As far as I remember, the idea with the Clippy lint was to allow it in
certain places like e.g. `assert()`s inside doctests for sure (and
perhaps in doctests in general). Thus no `// PANIC:` needed for
certain cases.

And here for `checkpatch.pl`, if it were to trigger in a similar
situation, then it would be a false positive, and thus the developer
should not add it. But the patch here skips if it is inside a comment
(or doctest), no?

So the remaining concern if I understand correctly is too many false
positives inside `#[test]`s but outside an `assert()`s? Yeah, we may
need to track if we have seen `kunit_tests` (and reset if we go out of
the test module), to skip a bunch of warnings.

By the way, I would prefer we expand the comment on top of the line
explaining what it is supposed to cover, in order to evaluate whether
the regexes etc. are doing what we expect or not.

Thanks Dirk et al. for diving into this -- we do need to move forward
this topic, and there have been some disagreements on how much is too
much to warn about :)

Cheers,
Miguel