[PATCH] scripts: checkpatch: warn on Rust panicking methods

[PATCH] scripts: checkpatch: warn on Rust panicking methods

[Jason Hall]

Added regex check in checkpatch.pl for common Rust panicking methods
like unwrap() and expect().

Allowed an exception if the line contains a '// PANIC:' comment.

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>
---
 scripts/checkpatch.pl | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index c0250244cf7a..fa9f55031129 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3834,6 +3834,17 @@ sub process {
 # check we are in a valid source file if not then ignore this hunk
 		next if ($realfile !~ /\.(h|c|rs|s|S|sh|dtsi|dts)$/);
 
+# check for Rust unwrap/expect
+		if ($realfile =~ /\.rs$/ && $line =~ /^\+/) {
+			if ($line =~ /\b(unwrap|expect)\s*\(/ &&
+				$rawline !~ /\/\/\s*PANIC/ &&
+				$line !~ /^\+\s*\/\// &&
+				$line !~ /^\+\s*assert/) {
+				WARN("RUST_UNWRAP",
+					"Avoid unwrap() or expect() in Rust code; use proper error handling (Result) or justify with a '// PANIC: ...' comment.\n" . $herecurr);
+			}
+		}
+
 # check for using SPDX-License-Identifier on the wrong line number
 		if ($realline != $checklicenseline &&
 		    $rawline =~ /\bSPDX-License-Identifier:/ &&
-- 
2.43.0

Re: [PATCH] scripts: checkpatch: warn on Rust panicking methods

[Charalampos Mitrodimas]

Jason Hall <jason.kei.hall@gmail.com> writes:

> Added regex check in checkpatch.pl for common Rust panicking methods
> like unwrap() and expect().
>
> Allowed an exception if the line contains a '// PANIC:' comment.
>
> 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>
> ---
>  scripts/checkpatch.pl | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index c0250244cf7a..fa9f55031129 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3834,6 +3834,17 @@ sub process {
>  # check we are in a valid source file if not then ignore this hunk
>  		next if ($realfile !~ /\.(h|c|rs|s|S|sh|dtsi|dts)$/);
>  
> +# check for Rust unwrap/expect
> +		if ($realfile =~ /\.rs$/ && $line =~ /^\+/) {
> +			if ($line =~ /\b(unwrap|expect)\s*\(/ &&

Using `\.` instead of `\b` would reduce false positives on string
literas. E.g. `println!("use unwrap() here")` would not trigger a
warning.

> +				$rawline !~ /\/\/\s*PANIC/ &&

Should this be:
       $rawline != /\/\/\s*PANIC:/ &&

i.e. with the colon?


Cheers,
C. Mitrodimas

> +				$line !~ /^\+\s*\/\// &&
> +				$line !~ /^\+\s*assert/) {
> +				WARN("RUST_UNWRAP",
> +					"Avoid unwrap() or expect() in Rust code; use proper error handling (Result) or justify with a '// PANIC: ...' comment.\n" . $herecurr);
> +			}
> +		}
> +
>  # check for using SPDX-License-Identifier on the wrong line number
>  		if ($realline != $checklicenseline &&
>  		    $rawline =~ /\bSPDX-License-Identifier:/ &&

[PATCH v2] scripts: checkpatch: warn on Rust panicking methods

[Jason Hall]

Added regex check in checkpatch.pl for common Rust panicking methods
like unwrap() and expect().

Allowed an exception if the line contains a '// PANIC:' comment.

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>
---
v2:
 - Switched from \b to (\.|::) to avoid false positives in strings.
 - Added : to PANIC comment check.
 scripts/checkpatch.pl | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index c0250244cf7a..43b4c0eebb96 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3834,6 +3834,17 @@ sub process {
 # check we are in a valid source file if not then ignore this hunk
 		next if ($realfile !~ /\.(h|c|rs|s|S|sh|dtsi|dts)$/);
 
+# check for Rust unwrap/expect
+		if ($realfile =~ /\.rs$/ && $line =~ /^\+/) {
+			if ($line =~ /(\.|::)(unwrap|expect)\s*\(/ &&
+				$rawline !~ /\/\/\s*PANIC:/ &&
+				$line !~ /^\+\s*\/\// &&
+				$line !~ /^\+\s*assert/) {
+				WARN("RUST_UNWRAP",
+					"Avoid unwrap() or expect() in Rust code; use proper error handling (Result) or justify with a '// PANIC: ...' comment.\n" . $herecurr);
+			}
+		}
+
 # check for using SPDX-License-Identifier on the wrong line number
 		if ($realline != $checklicenseline &&
 		    $rawline =~ /\bSPDX-License-Identifier:/ &&
-- 
2.43.0

Re: [PATCH v2] scripts: checkpatch: warn on Rust panicking methods

[Joe Perches]

On Sun, 2026-02-01 at 11:30 -0700, Jason Hall wrote:
> Added regex check in checkpatch.pl for common Rust panicking methods
> like unwrap() and expect().
> 
> Allowed an exception if the line contains a '// PANIC:' comment.

There's some desire to add rust comment checking.

https://lore.kernel.org/lkml/20260113211025.637889-1-foster.ryan.r@gmail.com/

Maybe this could be coordinated.

> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -3834,6 +3834,17 @@ sub process {
>  # check we are in a valid source file if not then ignore this hunk
>  		next if ($realfile !~ /\.(h|c|rs|s|S|sh|dtsi|dts)$/);
>  
> +# check for Rust unwrap/expect
> +		if ($realfile =~ /\.rs$/ && $line =~ /^\+/) {
> +			if ($line =~ /(\.|::)(unwrap|expect)\s*\(/ &&

Please use (?: to avoid capture groups

> +				$rawline !~ /\/\/\s*PANIC:/ &&
> +				$line !~ /^\+\s*\/\// &&
> +				$line !~ /^\+\s*assert/) {
> +				WARN("RUST_UNWRAP",
> +					"Avoid unwrap() or expect() in Rust code; use proper error handling (Result) or justify with a '// PANIC: ...' comment.\n" . $herecurr);
> +			}
> +		}

Re: [PATCH] scripts: checkpatch: warn on Rust panicking methods

[Gary Guo]

On Sun Feb 1, 2026 at 3:57 PM GMT, Jason Hall wrote:
> Added regex check in checkpatch.pl for common Rust panicking methods
> like unwrap() and expect().
>
> Allowed an exception if the line contains a '// PANIC:' comment.
>
> 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>
> ---
>  scripts/checkpatch.pl | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index c0250244cf7a..fa9f55031129 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3834,6 +3834,17 @@ sub process {
>  # check we are in a valid source file if not then ignore this hunk
>  		next if ($realfile !~ /\.(h|c|rs|s|S|sh|dtsi|dts)$/);
>  
> +# check for Rust unwrap/expect
> +		if ($realfile =~ /\.rs$/ && $line =~ /^\+/) {
> +			if ($line =~ /\b(unwrap|expect)\s*\(/ &&
> +				$rawline !~ /\/\/\s*PANIC/ &&
> +				$line !~ /^\+\s*\/\// &&
> +				$line !~ /^\+\s*assert/) {
> +				WARN("RUST_UNWRAP",
> +					"Avoid unwrap() or expect() in Rust code; use proper error handling (Result) or justify with a '// PANIC: ...' comment.\n" . $herecurr);

I don't think `expect()` should need be warned here. There's already
justification being given.

Best,
Gary


> +			}
> +		}
> +
>  # check for using SPDX-License-Identifier on the wrong line number
>  		if ($realline != $checklicenseline &&
>  		    $rawline =~ /\bSPDX-License-Identifier:/ &&

[PATCH v3] scripts: checkpatch: warn on Rust panicking methods

[Jason Hall]

Added regex check in checkpatch.pl for common Rust panicking methods
like unwrap() and expect().

Allowed an exception if the line contains a '// PANIC:' comment.

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>

Hi, Joe,

I updated the regex, and I looked at Ryan Foster's patch.  These two PANIC
checks don't seem to interfere with each other as far as I can see.
---
v3:
 - Using non-capturing groups (?:) to optimize regex.
v2:
 - Switched from \b to (\.|::) to avoid false positives in strings.
 - Added : to PANIC comment check.
 scripts/checkpatch.pl | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index c0250244cf7a..37bdf602e7e7 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3834,6 +3834,17 @@ sub process {
 # check we are in a valid source file if not then ignore this hunk
 		next if ($realfile !~ /\.(h|c|rs|s|S|sh|dtsi|dts)$/);
 
+# check for Rust unwrap/expect
+		if ($realfile =~ /\.rs$/ && $line =~ /^\+/) {
+			if ($line =~ /(?:\.|::)(?:unwrap|expect)\s*\(/ &&
+				$rawline !~ /\/\/\s*PANIC:/ &&
+				$line !~ /^\+\s*\/\// &&
+				$line !~ /^\+\s*assert/) {
+				WARN("RUST_UNWRAP",
+					"Avoid unwrap() or expect() in Rust code; use proper error handling (Result) or justify with a '// PANIC: ...' comment.\n" . $herecurr);
+			}
+		}
+
 # check for using SPDX-License-Identifier on the wrong line number
 		if ($realline != $checklicenseline &&
 		    $rawline =~ /\bSPDX-License-Identifier:/ &&
-- 
2.43.0

Re: [PATCH v3] scripts: checkpatch: warn on Rust panicking methods

[Dirk Behme]

Hi Jason,

On 01/02/2026 20:57, Jason Hall wrote:
> Added regex check in checkpatch.pl for common Rust panicking methods

Describe your changes in imperative mood. Added -> Add

> like unwrap() and expect().
> 
> Allowed an exception if the line contains a '// PANIC:' comment.

I recently came across that using `.unwrap()` in `tests` seems to be 
fine. E.g.:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/rust/kernel/alloc/kvec.rs#n1364

Is this covered here?

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

Something with the formatting seems to be wrong here? `---` is missing here?

Best regards

Dirk

> Hi, Joe,
> 
> I updated the regex, and I looked at Ryan Foster's patch.  These two PANIC
> checks don't seem to interfere with each other as far as I can see.
> ---
> v3:
>   - Using non-capturing groups (?:) to optimize regex.
> v2:
>   - Switched from \b to (\.|::) to avoid false positives in strings.
>   - Added : to PANIC comment check.
>   scripts/checkpatch.pl | 11 +++++++++++
>   1 file changed, 11 insertions(+)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index c0250244cf7a..37bdf602e7e7 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3834,6 +3834,17 @@ sub process {
>   # check we are in a valid source file if not then ignore this hunk
>   		next if ($realfile !~ /\.(h|c|rs|s|S|sh|dtsi|dts)$/);
>   
> +# check for Rust unwrap/expect
> +		if ($realfile =~ /\.rs$/ && $line =~ /^\+/) {
> +			if ($line =~ /(?:\.|::)(?:unwrap|expect)\s*\(/ &&
> +				$rawline !~ /\/\/\s*PANIC:/ &&
> +				$line !~ /^\+\s*\/\// &&
> +				$line !~ /^\+\s*assert/) {
> +				WARN("RUST_UNWRAP",
> +					"Avoid unwrap() or expect() in Rust code; use proper error handling (Result) or justify with a '// PANIC: ...' comment.\n" . $herecurr);
> +			}
> +		}
> +
>   # check for using SPDX-License-Identifier on the wrong line number
>   		if ($realline != $checklicenseline &&
>   		    $rawline =~ /\bSPDX-License-Identifier:/ &&

[PATCH v4] scripts: checkpatch: warn on Rust panicking methods

[Jason Hall]

Add regex check in checkpatch.pl for common Rust panicking methods
like unwrap() and expect().

Allow an exception if the line contains a '// PANIC:' comment.

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>
---
Hi Dirk,

Now using imperative mood.  I decided to keep that logic stateless
unless its agreed that we need to add state.  Adding checks for #[test]
and other test identifiers will make this much more complicated.  There
is already a check for // PANIC: that works fine.

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 | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index c0250244cf7a..37bdf602e7e7 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3834,6 +3834,17 @@ sub process {
 # check we are in a valid source file if not then ignore this hunk
 		next if ($realfile !~ /\.(h|c|rs|s|S|sh|dtsi|dts)$/);
 
+# check for Rust unwrap/expect
+		if ($realfile =~ /\.rs$/ && $line =~ /^\+/) {
+			if ($line =~ /(?:\.|::)(?:unwrap|expect)\s*\(/ &&
+				$rawline !~ /\/\/\s*PANIC:/ &&
+				$line !~ /^\+\s*\/\// &&
+				$line !~ /^\+\s*assert/) {
+				WARN("RUST_UNWRAP",
+					"Avoid unwrap() or expect() in Rust code; use proper error handling (Result) or justify with a '// PANIC: ...' comment.\n" . $herecurr);
+			}
+		}
+
 # check for using SPDX-License-Identifier on the wrong line number
 		if ($realline != $checklicenseline &&
 		    $rawline =~ /\bSPDX-License-Identifier:/ &&
-- 
2.43.0

Re: [PATCH v4] scripts: checkpatch: warn on Rust panicking methods

[Dirk Behme]

Hi Jason,

On 02/02/2026 14:56, Jason Hall wrote:
> Add regex check in checkpatch.pl for common Rust panicking methods
> like unwrap() and expect().
> 
> Allow an exception if the line contains a '// PANIC:' comment.
> 
> 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>
> ---
> Hi Dirk,
> 
> Now using imperative mood.  I decided to keep that logic stateless
> unless its agreed that we need to add state.  Adding checks for #[test]
> and other test identifiers will make this much more complicated.  There
> is already a check for // PANIC: that works fine.


Yes. I'm just slightly unclear what we do with existing code where using 
`unwrap()` is fine/accepted/required? And with patches like

https://lore.kernel.org/rust-for-linux/20260131154016.270385-3-shivamklr@cock.li/

I would guess with this change we would get warnings on that?

So the idea is that we would need some add-on patches on top of this to 
annotate existing code / patches with `// PANIC: ...` to stay warning clean?

Thanks,

Dirk

Btw, what's with Gary's comment to drop `expect()`?


> 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 | 11 +++++++++++
>   1 file changed, 11 insertions(+)
> 
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index c0250244cf7a..37bdf602e7e7 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3834,6 +3834,17 @@ sub process {
>   # check we are in a valid source file if not then ignore this hunk
>   		next if ($realfile !~ /\.(h|c|rs|s|S|sh|dtsi|dts)$/);
>   
> +# check for Rust unwrap/expect
> +		if ($realfile =~ /\.rs$/ && $line =~ /^\+/) {
> +			if ($line =~ /(?:\.|::)(?:unwrap|expect)\s*\(/ &&
> +				$rawline !~ /\/\/\s*PANIC:/ &&
> +				$line !~ /^\+\s*\/\// &&
> +				$line !~ /^\+\s*assert/) {
> +				WARN("RUST_UNWRAP",
> +					"Avoid unwrap() or expect() in Rust code; use proper error handling (Result) or justify with a '// PANIC: ...' comment.\n" . $herecurr);
> +			}
> +		}
> +
>   # check for using SPDX-License-Identifier on the wrong line number
>   		if ($realline != $checklicenseline &&
>   		    $rawline =~ /\bSPDX-License-Identifier:/ &&

Re: [PATCH v4] scripts: checkpatch: warn on Rust panicking methods

[Jkhall81]

Nice, emails sent from gmail get automatically rejected.

So, Dirk.  To satisfy your concerns the current 10ish line
code update is going to slowly, after many more emails
written in nano, mutate into a franken-regex-perl beast. 
checkpatch.pl is already huge.  I'm not a fan of this 
approach.

We could just not do this. Right now we are trying to
get a warning if someone uses rust code that can cause a
panic.  Software Engineers are smart people.  What if they
just don't use rust code that causes panics inside core
files.  Problem solved.

Re: [PATCH v4] scripts: checkpatch: warn on Rust panicking methods

[Onur Özkan]

On Tue,  3 Feb 2026 08:25:41 -0700
Jkhall81 <jason.kei.hall@gmail.com> wrote:

> Nice, emails sent from gmail get automatically rejected.
> 
> So, Dirk.  To satisfy your concerns the current 10ish line
> code update is going to slowly, after many more emails
> written in nano, mutate into a franken-regex-perl beast. 
> checkpatch.pl is already huge.  I'm not a fan of this 
> approach.

Me neither. I wonder why we are doing this instead of using the
unwrap_used and expect_used linting rules from clippy. This would
catch the problem much earlier than checkpath since many of us build
the kernel with CLIPPY=1 flag.

Regards,
Onur

> 
> We could just not do this. Right now we are trying to
> get a warning if someone uses rust code that can cause a
> panic.  Software Engineers are smart people.  What if they
> just don't use rust code that causes panics inside core
> files.  Problem solved.
> 
> 

Re: [PATCH v4] scripts: checkpatch: warn on Rust panicking methods

[Gary Guo]

On Tue Feb 3, 2026 at 3:49 PM GMT, Onur Özkan wrote:
> On Tue,  3 Feb 2026 08:25:41 -0700
> Jkhall81 <jason.kei.hall@gmail.com> wrote:
>
>> Nice, emails sent from gmail get automatically rejected.
>> 
>> So, Dirk.  To satisfy your concerns the current 10ish line
>> code update is going to slowly, after many more emails
>> written in nano, mutate into a franken-regex-perl beast. 
>> checkpatch.pl is already huge.  I'm not a fan of this 
>> approach.
>
> Me neither. I wonder why we are doing this instead of using the
> unwrap_used and expect_used linting rules from clippy. This would
> catch the problem much earlier than checkpath since many of us build
> the kernel with CLIPPY=1 flag.

Because it's okay to `panic` or use `expect`. checkpatch will just warn you
once when the code is introduced, not continuously in each build.

Best,
Gary

>
> Regards,
> Onur
>
>> 
>> We could just not do this. Right now we are trying to
>> get a warning if someone uses rust code that can cause a
>> panic.  Software Engineers are smart people.  What if they
>> just don't use rust code that causes panics inside core
>> files.  Problem solved.
>> 
>> 

Re: [PATCH v4] scripts: checkpatch: warn on Rust panicking methods

[Onur Özkan]

On Tue, 03 Feb 2026 16:02:02 +0000
"Gary Guo" <gary@garyguo.net> wrote:

> On Tue Feb 3, 2026 at 3:49 PM GMT, Onur Özkan wrote:
> > On Tue,  3 Feb 2026 08:25:41 -0700
> > Jkhall81 <jason.kei.hall@gmail.com> wrote:
> >
> >> Nice, emails sent from gmail get automatically rejected.
> >> 
> >> So, Dirk.  To satisfy your concerns the current 10ish line
> >> code update is going to slowly, after many more emails
> >> written in nano, mutate into a franken-regex-perl beast. 
> >> checkpatch.pl is already huge.  I'm not a fan of this 
> >> approach.
> >
> > Me neither. I wonder why we are doing this instead of using the
> > unwrap_used and expect_used linting rules from clippy. This would
> > catch the problem much earlier than checkpath since many of us build
> > the kernel with CLIPPY=1 flag.
> 
> Because it's okay to `panic` or use `expect`. checkpatch will just
> warn you once when the code is introduced, not continuously in each
> build.

That's interesting because it implies that it's okay for people to use
them without "// PANIC..." comments. That sounds problematic since it
means some instances will have that comment while others may not.

In my opinion, adding a clippy rule and using "#[allow(...)]" in the
places where it's acceptable to use them makes more sense. This is at
least more consistent and doesn't bloat the checkpatch file.

Thanks,
Onur

> 
> Best,
> Gary
> 
> >
> > Regards,
> > Onur
> >
> >> 
> >> We could just not do this. Right now we are trying to
> >> get a warning if someone uses rust code that can cause a
> >> panic.  Software Engineers are smart people.  What if they
> >> just don't use rust code that causes panics inside core
> >> files.  Problem solved.
> >> 
> >> 
> 

Re: [PATCH v4] scripts: checkpatch: warn on Rust panicking methods

[Gary Guo]

On Tue Feb 3, 2026 at 4:32 PM GMT, Onur Özkan wrote:
> On Tue, 03 Feb 2026 16:02:02 +0000
> "Gary Guo" <gary@garyguo.net> wrote:
>
>> On Tue Feb 3, 2026 at 3:49 PM GMT, Onur Özkan wrote:
>> > On Tue,  3 Feb 2026 08:25:41 -0700
>> > Jkhall81 <jason.kei.hall@gmail.com> wrote:
>> >
>> >> Nice, emails sent from gmail get automatically rejected.
>> >> 
>> >> So, Dirk.  To satisfy your concerns the current 10ish line
>> >> code update is going to slowly, after many more emails
>> >> written in nano, mutate into a franken-regex-perl beast. 
>> >> checkpatch.pl is already huge.  I'm not a fan of this 
>> >> approach.
>> >
>> > Me neither. I wonder why we are doing this instead of using the
>> > unwrap_used and expect_used linting rules from clippy. This would
>> > catch the problem much earlier than checkpath since many of us build
>> > the kernel with CLIPPY=1 flag.
>> 
>> Because it's okay to `panic` or use `expect`. checkpatch will just
>> warn you once when the code is introduced, not continuously in each
>> build.
>
> That's interesting because it implies that it's okay for people to use
> them without "// PANIC..." comments. That sounds problematic since it
> means some instances will have that comment while others may not.

My personal view has always been it's okay to not have it. It's a burden to
developers to always have to write these. In many cases, `panic()` or `expect()`
calls are needed because you have something of `Option<>` and you know it's not
going to be `None`. The C equivalent would just be a pointer and you use it
without checking for NULL; we never ask people to justify why they feel it's
okay to dereference a pointer.

Sure, if people would like to justify why they think it won't panic, brilliant,
keeping doing it. But I don't want to make it harder for people to write Rust
code compared to C.

>
> In my opinion, adding a clippy rule and using "#[allow(...)]" in the
> places where it's acceptable to use them makes more sense. This is at
> least more consistent and doesn't bloat the checkpatch file.

`#[allow()]` looks quite verbose, and also you cannot apply it everywhere (just
blocks or items).

Best,
Gary

Re: [PATCH v4] scripts: checkpatch: warn on Rust panicking methods

[Dirk Behme]

On 03.02.26 17:54, Gary Guo wrote:
> On Tue Feb 3, 2026 at 4:32 PM GMT, Onur Özkan wrote:
>> On Tue, 03 Feb 2026 16:02:02 +0000
>> "Gary Guo" <gary@garyguo.net> wrote:
>>
>>> On Tue Feb 3, 2026 at 3:49 PM GMT, Onur Özkan wrote:
>>>> On Tue,  3 Feb 2026 08:25:41 -0700
>>>> Jkhall81 <jason.kei.hall@gmail.com> wrote:
>>>>
>>>>> Nice, emails sent from gmail get automatically rejected.
>>>>>
>>>>> So, Dirk.  To satisfy your concerns the current 10ish line
>>>>> code update is going to slowly, after many more emails
>>>>> written in nano, mutate into a franken-regex-perl beast. 
>>>>> checkpatch.pl is already huge.  I'm not a fan of this 
>>>>> approach.
>>>>
>>>> Me neither. I wonder why we are doing this instead of using the
>>>> unwrap_used and expect_used linting rules from clippy. This would
>>>> catch the problem much earlier than checkpath since many of us build
>>>> the kernel with CLIPPY=1 flag.
>>>
>>> Because it's okay to `panic` or use `expect`. checkpatch will just
>>> warn you once when the code is introduced, not continuously in each
>>> build.
>>
>> That's interesting because it implies that it's okay for people to use
>> them without "// PANIC..." comments. That sounds problematic since it
>> means some instances will have that comment while others may not.
> 
> My personal view has always been it's okay to not have it. It's a burden to
> developers to always have to write these. In many cases, `panic()` or `expect()`
> calls are needed because you have something of `Option<>` and you know it's not
> going to be `None`. The C equivalent would just be a pointer and you use it
> without checking for NULL; we never ask people to justify why they feel it's
> okay to dereference a pointer.
> 
> Sure, if people would like to justify why they think it won't panic, brilliant,
> keeping doing it. But I don't want to make it harder for people to write Rust
> code compared to C.


The question is if we could find a way to make it *consistent*?

I mean how should a developer know if the warning (he gets once, or
even if he checks an existing file with -f always) is relevant or not?
We introduce the warning because we want to discourage the use of
`unwrap()`. At the same time there are places where its usage is
allowed or even needed. How to know what is valid? The warning or the
usage?

So do we find an acceptable way to mark the allowed ones? Or do we
drop this patch entirely and hope to catch the "forbidden" ones by
review? Or?

Best regards

Dirk


>> In my opinion, adding a clippy rule and using "#[allow(...)]" in the
>> places where it's acceptable to use them makes more sense. This is at
>> least more consistent and doesn't bloat the checkpatch file.
> 
> `#[allow()]` looks quite verbose, and also you cannot apply it everywhere (just
> blocks or items).
> 
> Best,
> Gary
> 
> 

Re: [PATCH v4] scripts: checkpatch: warn on Rust panicking methods

[Miguel Ojeda]

On Wed, Feb 4, 2026 at 4:56 PM Dirk Behme <dirk.behme@gmail.com> wrote:
>
> The question is if we could find a way to make it *consistent*?
>
> I mean how should a developer know if the warning (he gets once, or
> even if he checks an existing file with -f always) is relevant or not?
> We introduce the warning because we want to discourage the use of
> `unwrap()`. At the same time there are places where its usage is
> allowed or even needed. How to know what is valid? The warning or the
> usage?

I think usually developers use `checkpatch.pl` mostly on patches, not
existing files; plus it doesn't make the build fail. Thus I see
`checkpatch.pl` as a tool that can have way more false positives than
a linter that we need to keep strictly clean.

The idea with the `checkpatch.pl` warning was to have something we
could land easily before we got the new Clippy lints, and perhaps to
apply it in more cases than the eventual Clippy lint (since false
positives are not as concerning).

I have some context in
https://github.com/rust-lang/rust-clippy/issues/15895 -> "Additional
context", and a few other issues linked in
https://github.com/Rust-for-Linux/linux/issues/349 for the new lints.

Cheers,
Miguel

Re: [PATCH v4] scripts: checkpatch: warn on Rust panicking methods

[Miguel Ojeda]

On Tue, Feb 3, 2026 at 4:49 PM Onur Özkan <work@onurozkan.dev> wrote:
>
> Me neither. I wonder why we are doing this instead of using the
> unwrap_used and expect_used linting rules from clippy. This would
> catch the problem much earlier than checkpath since many of us build
> the kernel with CLIPPY=1 flag.

Please see my reply to Dirk and the context I link there, but
regarding the existing Clippy lints: we want to have the `// TAG`
style comments, rather than attributes, so we are waiting for the
Clippy lints on this.

Cheers,
Miguel

Re: [PATCH v4] scripts: checkpatch: warn on Rust panicking methods

[Joe Perches]

On Wed, 2026-02-04 at 19:10 +0100, Miguel Ojeda wrote:
> On Wed, Feb 4, 2026 at 4:56 PM Dirk Behme <dirk.behme@gmail.com> wrote:
> > 
> > The question is if we could find a way to make it *consistent*?
> > 
> > I mean how should a developer know if the warning (he gets once, or
> > even if he checks an existing file with -f always) is relevant or not?
> > We introduce the warning because we want to discourage the use of
> > `unwrap()`. At the same time there are places where its usage is
> > allowed or even needed. How to know what is valid? The warning or the
> > usage?
> 
> I think usually developers use `checkpatch.pl` mostly on patches, not
> existing files; plus it doesn't make the build fail. Thus I see
> `checkpatch.pl` as a tool that can have way more false positives than
> a linter that we need to keep strictly clean.
> 
> The idea with the `checkpatch.pl` warning was to have something we
> could land easily before we got the new Clippy lints, and perhaps to
> apply it in more cases than the eventual Clippy lint (since false
> positives are not as concerning).
> 
> I have some context in
> https://github.com/rust-lang/rust-clippy/issues/15895 -> "Additional
> context", and a few other issues linked in
> https://github.com/Rust-for-Linux/linux/issues/349 for the new lints.

Maybe adding something like this to checkpatch so rust
specific checks and possibly other execs could be added
relatively easily in checkpatch's process() 

	process_rust() if ($realfile =~ /\.rs$/);

---
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e56374662ff79..bd9daa77470a5 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -20,6 +20,8 @@ my $D = dirname(abs_path($P));
 
 my $V = '0.32';
 
+require "$D/rust_checkpatch.pl";
+
 use Getopt::Long qw(:config no_auto_abbrev);
 
 my $quiet = 0;

[PATCH v5] scripts: checkpatch: move Rust-specific lints to separate file

[Jason Hall]

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

Re: [PATCH v4] scripts: checkpatch: warn on Rust panicking methods

[Dirk Behme]

On 04.02.2026 19:10, Miguel Ojeda wrote:
> On Wed, Feb 4, 2026 at 4:56 PM Dirk Behme <dirk.behme@gmail.com> wrote:
>>
>> The question is if we could find a way to make it *consistent*?
>>
>> I mean how should a developer know if the warning (he gets once, or
>> even if he checks an existing file with -f always) is relevant or not?
>> We introduce the warning because we want to discourage the use of
>> `unwrap()`. At the same time there are places where its usage is
>> allowed or even needed. How to know what is valid? The warning or the
>> usage?
> 
> I think usually developers use `checkpatch.pl` mostly on patches, not
> existing files; plus it doesn't make the build fail. Thus I see
> `checkpatch.pl` as a tool that can have way more false positives than
> a linter that we need to keep strictly clean.

And how would a developer know that a `checkpatch.pl` warning on 
`unwrap()` is a false positive or not (i.e. is to be fixed)?

Thanks

Dirk


> The idea with the `checkpatch.pl` warning was to have something we
> could land easily before we got the new Clippy lints, and perhaps to
> apply it in more cases than the eventual Clippy lint (since false
> positives are not as concerning).
> 
> I have some context in
> https://github.com/rust-lang/rust-clippy/issues/15895 -> "Additional
> context", and a few other issues linked in
> https://github.com/Rust-for-Linux/linux/issues/349 for the new lints.
> 
> Cheers,
> Miguel

Re: [PATCH v5] scripts: checkpatch: move Rust-specific lints to separate file

[Miguel Ojeda]

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

Re: [PATCH v4] scripts: checkpatch: warn on Rust panicking methods

[Miguel Ojeda]

On Thu, Feb 5, 2026 at 2:24 PM Dirk Behme <dirk.behme@de.bosch.com> wrote:
>
> And how would a developer know that a `checkpatch.pl` warning on
> `unwrap()` is a false positive or not (i.e. is to be fixed)?

It depends on the context, like some other `checkpatch.pl`
errors/warnings, i.e. there is always some degree of developer
discretion. Or, at least, that is the way I think about
`checkpatch.pl` warnings, but maybe the maintainers think otherwise
(Cc'ing).

To give concrete advice, we could perhaps link to
https://rust.docs.kernel.org/kernel/error/type.Result.html#error-codes-in-c-and-rust,
for instance. (Please see my other reply on v5 about it).

Cheers,
Miguel

Re: [PATCH v5] scripts: checkpatch: move Rust-specific lints to separate file

[Dirk Behme]

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

Re: [PATCH v5] scripts: checkpatch: move Rust-specific lints to separate file

[Miguel Ojeda]

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

[PATCH v6] scripts: checkpatch: move Rust-specific lints to separate file

[Jason Hall]

Create scripts/rust_checkpatch.pl for Rust-specific linting logic.
Add a conditional loading hook in scripts/checkpatch.pl to call it.
This will allow Rust linting logic to be maintained independently.

Add a new entry to the MAINTAINERS file to track this new file.

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>

---
---
 MAINTAINERS                |  6 ++++++
 scripts/rust_checkpatch.pl | 15 +++------------
 2 files changed, 9 insertions(+), 12 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2c0bdd08b74c..57831dc30e6b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5880,6 +5880,12 @@ R:	Lukas Bulwahn <lukas.bulwahn@gmail.com>
 S:	Maintained
 F:	scripts/checkpatch.pl
 
+CHECKPATCH RUST LINTS
+M:	Jason Hall <jason.kei.hall@gmail.com>
+L:	rust-for-linux@vger.kernel.org
+S:	Maintained
+F:	scripts/rust_checkpatch.pl
+
 CHECKPATCH DOCUMENTATION
 M:	Dwaipayan Ray <dwaipayanray1@gmail.com>
 M:	Lukas Bulwahn <lukas.bulwahn@gmail.com>
diff --git a/scripts/rust_checkpatch.pl b/scripts/rust_checkpatch.pl
index 69db5ded7371..56c1bc29d3f2 100644
--- a/scripts/rust_checkpatch.pl
+++ b/scripts/rust_checkpatch.pl
@@ -1,7 +1,7 @@
 #!/usr/bin/env perl
 # SPDX-License-Identifier: GPL-2.0
 #
-# (c) 2026, Jason K. Hall <jason.kei.hall@gmail.com>
+# (c) 2026, Jason Hall <jason.kei.hall@gmail.com>
 
 use strict;
 use warnings;
@@ -9,17 +9,8 @@ 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);
-        }
-    }
+    # Reserve for future Rust-specific lints
     return ();
 }
 
-1;
\ No newline at end of file
+1;
-- 
2.43.0

Re: [PATCH v6] scripts: checkpatch: move Rust-specific lints to separate file

[Miguel Ojeda]

On Sat, Feb 7, 2026 at 4:56 PM Jason Hall <jason.kei.hall@gmail.com> wrote:
>
> Link: https://github.com/Rust-for-linux/linux/issues/1191

I guess the link doesn't hurt, but the link is a bit tangential for
this patch (unlike the other one, of course).

> -# (c) 2026, Jason K. Hall <jason.kei.hall@gmail.com>
> +# (c) 2026, Jason Hall <jason.kei.hall@gmail.com>

Unrelated change?

> -    # 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);
> -        }
> -    }

This diff seems to be based on the previous patches. Each version of a
series should be a rebase, not a stack.

Thanks!

Cheers,
Miguel

[PATCH v7] scripts: checkpatch: move Rust-specific lints to separate file

[Jason Hall]

Create scripts/rust_checkpatch.pl for Rust-specific linting logic.
Add a conditional loading hook in scripts/checkpatch.pl to call it.
This will allow Rust linting logic to be maintained independently.

Add a new entry to the MAINTAINERS file to track this new file.

Suggested-by: Joe Perches <joe@perches.com>
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Jason Hall <jason.kei.hall@gmail.com>

---
---
 MAINTAINERS                |  6 ++++++
 scripts/checkpatch.pl      | 14 ++++++++++++++
 scripts/rust_checkpatch.pl | 16 ++++++++++++++++
 3 files changed, 36 insertions(+)
 create mode 100644 scripts/rust_checkpatch.pl

diff --git a/MAINTAINERS b/MAINTAINERS
index 2c0bdd08b74c..57831dc30e6b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5880,6 +5880,12 @@ R:	Lukas Bulwahn <lukas.bulwahn@gmail.com>
 S:	Maintained
 F:	scripts/checkpatch.pl
 
+CHECKPATCH RUST LINTS
+M:	Jason Hall <jason.kei.hall@gmail.com>
+L:	rust-for-linux@vger.kernel.org
+S:	Maintained
+F:	scripts/rust_checkpatch.pl
+
 CHECKPATCH DOCUMENTATION
 M:	Dwaipayan Ray <dwaipayanray1@gmail.com>
 M:	Lukas Bulwahn <lukas.bulwahn@gmail.com>
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..56c1bc29d3f2
--- /dev/null
+++ b/scripts/rust_checkpatch.pl
@@ -0,0 +1,16 @@
+#!/usr/bin/env perl
+# SPDX-License-Identifier: GPL-2.0
+#
+# (c) 2026, Jason Hall <jason.kei.hall@gmail.com>
+
+use strict;
+use warnings;
+
+sub process_rust {
+    my ($line, $rawline, $herecurr) = @_;
+
+    # Reserve for future Rust-specific lints
+    return ();
+}
+
+1;
-- 
2.43.0

Re: [PATCH v7] scripts: checkpatch: move Rust-specific lints to separate file

[Miguel Ojeda]

On Sat, Feb 7, 2026 at 5:53 PM Jason Hall <jason.kei.hall@gmail.com> wrote:
>
> Create scripts/rust_checkpatch.pl for Rust-specific linting logic.
> Add a conditional loading hook in scripts/checkpatch.pl to call it.
> This will allow Rust linting logic to be maintained independently.
>
> Add a new entry to the MAINTAINERS file to track this new file.
>
> Suggested-by: Joe Perches <joe@perches.com>
> Suggested-by: Miguel Ojeda <ojeda@kernel.org>
> Signed-off-by: Jason Hall <jason.kei.hall@gmail.com>

This is better, and perhaps the maintainers decide to take it on its
own, but what I meant by splitting in 2 patches before was that this
should be a series of 2 patches. The first would be this one, and the
second would add the lint. Otherwise, the first one doesn't really do
much, since there would be no lint yet.

https://docs.kernel.org/process/submitting-patches.html#the-canonical-patch-format
explain a bit how patch series work.

In addition, you are still not Cc'ing all the maintainers and
reviewers. Please do so by Cc'ing them -- the addresses are in
`MAINTAINERS` file, and you should look at the "RUST" and "CHECKPATCH"
entries.

Thanks!

Cheers,
Miguel

[PATCH v8 0/2] modularize Rust lints and add RUST_UNWRAP check

[Jason Hall]

This series moves Rust-specific linting logic into a separate file to
prevent further growth of the main scripts/checkpatch.pl script and
introduces a new lint to enforce safety standards.

The first patch creates the infrastructure for scripts/rust_checkpatch.pl
and adds a conditional loading hook in the main checkpatch script. It
also updates the MAINTAINERS file to track this new file.

The second patch introduces the  RUST_UNWRAP lint, which warns against
the use of .unwrap() and .expect() unless they are accompanied by a 
'// PANIC:' justification comment.

Jason Hall (2):
  scripts: checkpatch: move Rust-specific lints to separate file
  scripts: checkpatch: add RUST_UNWRAP lint

 MAINTAINERS                | 22 ++++++++++++++--------
 scripts/checkpatch.pl      | 14 ++++++++++++++
 scripts/rust_checkpatch.pl | 30 ++++++++++++++++++++++++++++++
 3 files changed, 58 insertions(+), 8 deletions(-)
 create mode 100644 scripts/rust_checkpatch.pl

-- 
2.43.0

[PATCH v8 1/2] scripts: checkpatch: move Rust-specific lints to separate file

[Jason Hall]

Create scripts/rust_checkpatch.pl for Rust-specific linting logic.
Add a conditional loading hook in scripts/checkpatch.pl to call it.
This will allow Rust linting logic to be maintained independently.

Add a new entry to the MAINTAINERS file to track this new file.

Suggested-by: Joe Perches <joe@perches.com>
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Jason Hall <jason.kei.hall@gmail.com>
---
 MAINTAINERS                | 22 ++++++++++++++--------
 scripts/checkpatch.pl      | 14 ++++++++++++++
 scripts/rust_checkpatch.pl | 16 ++++++++++++++++
 3 files changed, 44 insertions(+), 8 deletions(-)
 create mode 100644 scripts/rust_checkpatch.pl

diff --git a/MAINTAINERS b/MAINTAINERS
index f6bc65de83c7..57831dc30e6b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4109,7 +4109,7 @@ F:	drivers/input/touchscreen/atmel_mxt_ts.c
 ATOMIC INFRASTRUCTURE
 M:	Will Deacon <will@kernel.org>
 M:	Peter Zijlstra <peterz@infradead.org>
-M:	Boqun Feng <boqun.feng@gmail.com>
+M:	Boqun Feng <boqun@kernel.org>
 R:	Mark Rutland <mark.rutland@arm.com>
 R:	Gary Guo <gary@garyguo.net>
 L:	linux-kernel@vger.kernel.org
@@ -4500,7 +4500,7 @@ F:	lib/sbitmap.c
 
 BLOCK LAYER DEVICE DRIVER API [RUST]
 M:	Andreas Hindborg <a.hindborg@kernel.org>
-R:	Boqun Feng <boqun.feng@gmail.com>
+R:	Boqun Feng <boqun@kernel.org>
 L:	linux-block@vger.kernel.org
 L:	rust-for-linux@vger.kernel.org
 S:	Supported
@@ -5880,6 +5880,12 @@ R:	Lukas Bulwahn <lukas.bulwahn@gmail.com>
 S:	Maintained
 F:	scripts/checkpatch.pl
 
+CHECKPATCH RUST LINTS
+M:	Jason Hall <jason.kei.hall@gmail.com>
+L:	rust-for-linux@vger.kernel.org
+S:	Maintained
+F:	scripts/rust_checkpatch.pl
+
 CHECKPATCH DOCUMENTATION
 M:	Dwaipayan Ray <dwaipayanray1@gmail.com>
 M:	Lukas Bulwahn <lukas.bulwahn@gmail.com>
@@ -11264,7 +11270,7 @@ F:	tools/testing/selftests/timers/
 
 DELAY, SLEEP, TIMEKEEPING, TIMERS [RUST]
 M:	Andreas Hindborg <a.hindborg@kernel.org>
-R:	Boqun Feng <boqun.feng@gmail.com>
+R:	Boqun Feng <boqun@kernel.org>
 R:	FUJITA Tomonori <fujita.tomonori@gmail.com>
 R:	Frederic Weisbecker <frederic@kernel.org>
 R:	Lyude Paul <lyude@redhat.com>
@@ -14559,7 +14565,7 @@ M:	Alan Stern <stern@rowland.harvard.edu>
 M:	Andrea Parri <parri.andrea@gmail.com>
 M:	Will Deacon <will@kernel.org>
 M:	Peter Zijlstra <peterz@infradead.org>
-M:	Boqun Feng <boqun.feng@gmail.com>
+M:	Boqun Feng <boqun@kernel.org>
 M:	Nicholas Piggin <npiggin@gmail.com>
 M:	David Howells <dhowells@redhat.com>
 M:	Jade Alglave <j.alglave@ucl.ac.uk>
@@ -14718,7 +14724,7 @@ LOCKING PRIMITIVES
 M:	Peter Zijlstra <peterz@infradead.org>
 M:	Ingo Molnar <mingo@redhat.com>
 M:	Will Deacon <will@kernel.org>
-M:	Boqun Feng <boqun.feng@gmail.com> (LOCKDEP & RUST)
+M:	Boqun Feng <boqun@kernel.org> (LOCKDEP & RUST)
 R:	Waiman Long <longman@redhat.com>
 L:	linux-kernel@vger.kernel.org
 S:	Maintained
@@ -21912,7 +21918,7 @@ M:	Frederic Weisbecker <frederic@kernel.org> (kernel/rcu/tree_nocb.h)
 M:	Neeraj Upadhyay <neeraj.upadhyay@kernel.org> (kernel/rcu/tasks.h)
 M:	Joel Fernandes <joelagnelf@nvidia.com>
 M:	Josh Triplett <josh@joshtriplett.org>
-M:	Boqun Feng <boqun.feng@gmail.com>
+M:	Boqun Feng <boqun@kernel.org>
 M:	Uladzislau Rezki <urezki@gmail.com>
 R:	Steven Rostedt <rostedt@goodmis.org>
 R:	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
@@ -22362,7 +22368,7 @@ RESTARTABLE SEQUENCES SUPPORT
 M:	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
 M:	Peter Zijlstra <peterz@infradead.org>
 M:	"Paul E. McKenney" <paulmck@kernel.org>
-M:	Boqun Feng <boqun.feng@gmail.com>
+M:	Boqun Feng <boqun@kernel.org>
 L:	linux-kernel@vger.kernel.org
 S:	Supported
 F:	include/trace/events/rseq.h
@@ -22885,7 +22891,7 @@ F:	tools/verification/
 
 RUST
 M:	Miguel Ojeda <ojeda@kernel.org>
-R:	Boqun Feng <boqun.feng@gmail.com>
+R:	Boqun Feng <boqun@kernel.org>
 R:	Gary Guo <gary@garyguo.net>
 R:	Björn Roy Baron <bjorn3_gh@protonmail.com>
 R:	Benno Lossin <lossin@kernel.org>
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..56c1bc29d3f2
--- /dev/null
+++ b/scripts/rust_checkpatch.pl
@@ -0,0 +1,16 @@
+#!/usr/bin/env perl
+# SPDX-License-Identifier: GPL-2.0
+#
+# (c) 2026, Jason Hall <jason.kei.hall@gmail.com>
+
+use strict;
+use warnings;
+
+sub process_rust {
+    my ($line, $rawline, $herecurr) = @_;
+
+    # Reserve for future Rust-specific lints
+    return ();
+}
+
+1;
-- 
2.43.0

[PATCH v8 2/2] scripts: checkpatch: add RUST_UNWRAP lint

[Jason Hall]

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: 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>
---
 scripts/rust_checkpatch.pl | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/scripts/rust_checkpatch.pl b/scripts/rust_checkpatch.pl
index 56c1bc29d3f2..9a4e256a4ec4 100644
--- a/scripts/rust_checkpatch.pl
+++ b/scripts/rust_checkpatch.pl
@@ -9,7 +9,21 @@ use warnings;
 sub process_rust {
     my ($line, $rawline, $herecurr) = @_;
 
-    # Reserve for future Rust-specific lints
+    # Check for Rust unwrap/expect usage.
+    # We skip lines that are already comments, assert macros (common in tests),
+    # or have a '// PANIC:' justification.
+    if ($line =~ /^\+/) {
+        if ($line =~ /(?:\.|::)(?:unwrap|expect)\s*\(/ &&
+            $rawline !~ /\/\/\s*PANIC:/ &&
+            $line !~ /^\+\s*\/\// &&
+            $line !~ /^\+\s*assert/) {
+            return ("RUST_UNWRAP",
+                    "unwrap() and expect() should generally be avoided in Rust kernel code.\n" .
+                    "If the use is intended, please justify it with a '// PANIC:' comment.\n" .
+                    "See: https://rust.docs.kernel.org/kernel/error/type.Result.html#error-codes-in-c-and-rust\n" .
+                    $herecurr);
+        }
+    }
     return ();
 }
 
-- 
2.43.0

Re: [PATCH v8 1/2] scripts: checkpatch: move Rust-specific lints to separate file

[Miguel Ojeda]

On Sat, Feb 7, 2026 at 10:08 PM Jason Hall <jason.kei.hall@gmail.com> wrote:
>
> -M:     Boqun Feng <boqun.feng@gmail.com>
> +M:     Boqun Feng <boqun@kernel.org>

This is now a patch series, great!

But please review your patches before sending them -- this has a lot
of unrelated changes again.

I suspect you are copying files around, to re-create commits in
another base manually, instead of using `git` commands like `git
rebase`.

Cheers,
Miguel

[PATCH v9 0/2] modularize Rust lints and add RUST_UNWRAP check

[Jason Hall]

This series moves Rust-specific linting logic into a separate file to
prevent further growth of the main scripts/checkpatch.pl script and
introduces a new lint to enforce safety standards.

The first patch creates the infrastructure for scripts/rust_checkpatch.pl
and adds a conditional loading hook in the main checkpatch script. It
also updates the MAINTAINERS file to track this new file.

The second patch introduces the  RUST_UNWRAP lint, which warns against
the use of .unwrap() and .expect() unless they are accompanied by a 
'// PANIC:' justification comment.

Jason Hall (2):
  scripts: checkpatch: move Rust-specific lints to separate file
  scripts: checkpatch: add RUST_UNWRAP lint

 MAINTAINERS                |  6 ++++++
 scripts/checkpatch.pl      | 14 ++++++++++++++
 scripts/rust_checkpatch.pl | 30 ++++++++++++++++++++++++++++++
 3 files changed, 50 insertions(+)
 create mode 100644 scripts/rust_checkpatch.pl

-- 
2.43.0

[PATCH v9 1/2] scripts: checkpatch: move Rust-specific lints to separate file

[Jason Hall]

Create scripts/rust_checkpatch.pl for Rust-specific linting logic.
Add a conditional loading hook in scripts/checkpatch.pl to call it.
This will allow Rust linting logic to be maintained independently.

Add a new entry to the MAINTAINERS file to track this new file.

Suggested-by: Joe Perches <joe@perches.com>
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Jason Hall <jason.kei.hall@gmail.com>
---
 MAINTAINERS                |  6 ++++++
 scripts/checkpatch.pl      | 14 ++++++++++++++
 scripts/rust_checkpatch.pl | 16 ++++++++++++++++
 3 files changed, 36 insertions(+)
 create mode 100644 scripts/rust_checkpatch.pl

diff --git a/MAINTAINERS b/MAINTAINERS
index 2c0bdd08b74c..57831dc30e6b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5880,6 +5880,12 @@ R:	Lukas Bulwahn <lukas.bulwahn@gmail.com>
 S:	Maintained
 F:	scripts/checkpatch.pl
 
+CHECKPATCH RUST LINTS
+M:	Jason Hall <jason.kei.hall@gmail.com>
+L:	rust-for-linux@vger.kernel.org
+S:	Maintained
+F:	scripts/rust_checkpatch.pl
+
 CHECKPATCH DOCUMENTATION
 M:	Dwaipayan Ray <dwaipayanray1@gmail.com>
 M:	Lukas Bulwahn <lukas.bulwahn@gmail.com>
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..56c1bc29d3f2
--- /dev/null
+++ b/scripts/rust_checkpatch.pl
@@ -0,0 +1,16 @@
+#!/usr/bin/env perl
+# SPDX-License-Identifier: GPL-2.0
+#
+# (c) 2026, Jason Hall <jason.kei.hall@gmail.com>
+
+use strict;
+use warnings;
+
+sub process_rust {
+    my ($line, $rawline, $herecurr) = @_;
+
+    # Reserve for future Rust-specific lints
+    return ();
+}
+
+1;
-- 
2.43.0

[PATCH v9 2/2] scripts: checkpatch: add RUST_UNWRAP lint

[Jason Hall]

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: 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>
---
 scripts/rust_checkpatch.pl | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/scripts/rust_checkpatch.pl b/scripts/rust_checkpatch.pl
index 56c1bc29d3f2..fa7adaed264c 100644
--- a/scripts/rust_checkpatch.pl
+++ b/scripts/rust_checkpatch.pl
@@ -9,7 +9,21 @@ use warnings;
 sub process_rust {
     my ($line, $rawline, $herecurr) = @_;
 
-    # Reserve for future Rust-specific lints
+    # Check for Rust unwrap/expect usage.
+    # We skip lines that are already comments, assert macros (common in tests),
+    # or have a '// PANIC:' justification.
+    if ($line =~ /^\+/) {
+        if ($line =~ /(?:\.|::)(?:unwrap|expect)\s*\(/ &&
+            $rawline !~ /\/\/\s*PANIC:/ &&
+            $line !~ /^\+\s*\/\// &&
+            $line !~ /^\+\s*assert/) {
+            return ("RUST_UNWRAP",
+                    "unwrap() and expect() should generally be avoided in Rust kernel code.\n" .
+                   "If the use is intended, please justify it with a '// PANIC:' comment.\n" .
+                    "See: https://rust.docs.kernel.org/kernel/error/type.Result.html#error-codes-in-c-and-rust\n" .
+                    $herecurr);
+        }
+    }
     return ();
 }
 
-- 
2.43.0

Re: [PATCH v9 0/2] modularize Rust lints and add RUST_UNWRAP check

[Greg KH]

On Sat, Feb 07, 2026 at 03:49:05PM -0700, Jason Hall wrote:
> This series moves Rust-specific linting logic into a separate file to
> prevent further growth of the main scripts/checkpatch.pl script and
> introduces a new lint to enforce safety standards.
> 
> The first patch creates the infrastructure for scripts/rust_checkpatch.pl
> and adds a conditional loading hook in the main checkpatch script. It
> also updates the MAINTAINERS file to track this new file.
> 
> The second patch introduces the  RUST_UNWRAP lint, which warns against
> the use of .unwrap() and .expect() unless they are accompanied by a 
> '// PANIC:' justification comment.
> 
> Jason Hall (2):
>   scripts: checkpatch: move Rust-specific lints to separate file
>   scripts: checkpatch: add RUST_UNWRAP lint
> 
>  MAINTAINERS                |  6 ++++++
>  scripts/checkpatch.pl      | 14 ++++++++++++++
>  scripts/rust_checkpatch.pl | 30 ++++++++++++++++++++++++++++++
>  3 files changed, 50 insertions(+)
>  create mode 100644 scripts/rust_checkpatch.pl
> 
> -- 
> 2.43.0
> 
> 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- This looks like a new version of a previously submitted patch, but you
  did not list below the --- line any changes from the previous version.
  Please read the section entitled "The canonical patch format" in the
  kernel file, Documentation/process/submitting-patches.rst for what
  needs to be done here to properly describe this.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

Re: [PATCH v9 2/2] scripts: checkpatch: add RUST_UNWRAP lint

[Dirk Behme]

On 07.02.26 23:49, Jason Hall wrote:
> 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.


I wonder if we could add some outcome from the mailing list discussion
to the commit message? E.g. what we consider to be false positives,
the handling of them and what we suppose to be fixed etc.


> 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>
> ---
>  scripts/rust_checkpatch.pl | 16 +++++++++++++++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/rust_checkpatch.pl b/scripts/rust_checkpatch.pl
> index 56c1bc29d3f2..fa7adaed264c 100644
> --- a/scripts/rust_checkpatch.pl
> +++ b/scripts/rust_checkpatch.pl
> @@ -9,7 +9,21 @@ use warnings;
>  sub process_rust {
>      my ($line, $rawline, $herecurr) = @_;
>  
> -    # Reserve for future Rust-specific lints
> +    # Check for Rust unwrap/expect usage.
> +    # We skip lines that are already comments, assert macros (common in tests),
> +    # or have a '// PANIC:' justification.
> +    if ($line =~ /^\+/) {
> +        if ($line =~ /(?:\.|::)(?:unwrap|expect)\s*\(/ &&


Whats about the `.expect()` topic discussed in

https://lore.kernel.org/rust-for-linux/a798e6a368639f7a1ce633a6dfecd088d6ed4123.camel@perches.com/T/#m00723ad673727036e5fcf96a35f2f231ec9de31f

https://lore.kernel.org/rust-for-linux/a798e6a368639f7a1ce633a6dfecd088d6ed4123.camel@perches.com/T/#m5604274a633ef33eb474f95b54f797843d0fe1dd

?

> +            $rawline !~ /\/\/\s*PANIC:/ &&
> +            $line !~ /^\+\s*\/\// &&
> +            $line !~ /^\+\s*assert/) {
> +            return ("RUST_UNWRAP",
> +                    "unwrap() and expect() should generally be avoided in Rust kernel code.\n" .
> +                   "If the use is intended, please justify it with a '// PANIC:' comment.\n" .
> +                    "See: https://rust.docs.kernel.org/kernel/error/type.Result.html#error-codes-in-c-and-rust\n" .
> +                    $herecurr);
> +        }
> +    }
>      return ();
>  }

Just for the logs:

Running this on e.g.

https://lore.kernel.org/rust-for-linux/20260207-binder-shrink-vec-v3-v3-3-8ff388563427@cock.li/

gives


$ ./scripts/checkpatch.pl
0001-rust-alloc-add-KUnit-tests-for-Vec-shrink-operations.patch
WARNING: unwrap() and expect() should generally be avoided in Rust
kernel code.
If the use is intended, please justify it with a '// PANIC:' comment.
See:
https://rust.docs.kernel.org/kernel/error/type.Result.html#error-codes-in-c-and-rust
#52: FILE: rust/kernel/alloc/kvec.rs:1524:
+        let mut v: VVec<u32> = VVec::with_capacity(initial_capacity,
GFP_KERNEL).unwrap();

...

total: 0 errors, 21 warnings, 189 lines checked

(note: all 21 warnings are from `unwrap()`)

I'm not sure if it makes me happy to ignore these 21 warnings as false
positives ;)

Best regards

Dirk

Re: [PATCH v9 2/2] scripts: checkpatch: add RUST_UNWRAP lint

[Jason Hall]

Hi Dirk,

I have been playing around with the lint logic. It now identifies 
when we enter a test-related block (like mod tests, #[test], or KUnit 
macros) and suppresses the warning for that specific context. 

This handles the false positives you encountered in the Binder patch 
while still catching "lazy" unwraps in production logic.

I tested the scenarios laid out below.

Proposed Logic:

my $in_rust_test_context = 0;

sub process_rust {
    my ($line, $rawline, $herecurr) = @_;

    if ($rawline =~ /^(?:@@|diff --git)/) {
        $in_rust_test_context = 0;
    }

    if ($line =~ /^\+\s*(?:mod\s+tests|#\[.*(?:test|kunit))/) {
        $in_rust_test_context = 1;
    }

    if ($line =~ /^\+/ && !$in_rust_test_context) {
        if ($line =~ /(?:\.|::)(?:unwrap|expect)\s*\(/ &&
            $rawline !~ /\/\/\s*PANIC:/ &&
            $line !~ /^\+\s*\/\// &&
            $line !~ /^\+\s*assert/) {
            return ("RUST_UNWRAP", "...");
        }
    }
    return ();
}

Scenarios:

--- a/rust/kernel/alloc/kvec.rs
+++ b/rust/kernel/alloc/kvec.rs
@@ -42,6 +42,7 @@
     pub fn new_with_data() -> Self {
-        let x = Some(1);
+        // Scenario 1: Production code (SHOULD WARN)
+        let val = some_kernel_function().unwrap();
         Vec { ptr: NonNull::dangling(), len: 0 }
     }
 
@@ -150,6 +151,13 @@
+    // Scenario 2: Explicitly justified (SHOULD NOT WARN)
+    pub fn proof_of_concept() {
+        let x = core::ptr::NonNull::new(ptr).unwrap(); // PANIC: ptr is never null here
+    }
+
+    // Scenario 3: Already a comment (SHOULD NOT WARN)
+    // let x = something.unwrap();
+
@@ -200,10 +208,20 @@
+#[test]
+fn scenario_4_standalone_test() {
+    // SHOULD NOT WARN because of #[test] above
+    let v: KVec<u32> = KVec::with_capacity(1, GFP_KERNEL).unwrap();
+}
+
+#[macros::kunit_tests(rust_kvec)]
+mod tests {
+    use super::*;
+
+    fn test_internal_logic() {
+        // Scenario 5: Inside KUnit mod (SHOULD NOT WARN)
+        // Dirk's specific 21 warnings happened in a block like this.
+        let mut v = KVec::new();
+        v.push(1, GFP_KERNEL).unwrap();
+        assert_eq!(v.pop().unwrap(), 1);
+    }
+}

If this looks okay, I can resubmit the patch series with this.

Best regards,
Jason

Re: [PATCH v9 2/2] scripts: checkpatch: add RUST_UNWRAP lint

[Dirk Behme]

On 08.02.2026 15:01, Jason Hall wrote:
> Hi Dirk,
> 
> I have been playing around with the lint logic. It now identifies
> when we enter a test-related block (like mod tests, #[test], or KUnit
> macros) and suppresses the warning for that specific context.
> 
> This handles the false positives you encountered in the Binder patch
> while still catching "lazy" unwraps in production logic.
> 
> I tested the scenarios laid out below.


I appreciate that its not an easy exercise. So many thanks for this! :)


> Proposed Logic:
> 
> my $in_rust_test_context = 0;
> 
> sub process_rust {
>      my ($line, $rawline, $herecurr) = @_;
> 
>      if ($rawline =~ /^(?:@@|diff --git)/) {
>          $in_rust_test_context = 0;
>      }
> 
>      if ($line =~ /^\+\s*(?:mod\s+tests|#\[.*(?:test|kunit))/) {
>          $in_rust_test_context = 1;
>      }


This implies that the "allowed" usages in tests are always at the end of 
a file? This seems to be the case at the moment? But I'm not sure if 
this holds in general?

And this won't work with `-f`? But I think this use case was somehow 
excluded by Miguel, already.

Thanks again,

Dirk


>      if ($line =~ /^\+/ && !$in_rust_test_context) {
>          if ($line =~ /(?:\.|::)(?:unwrap|expect)\s*\(/ &&
>              $rawline !~ /\/\/\s*PANIC:/ &&
>              $line !~ /^\+\s*\/\// &&
>              $line !~ /^\+\s*assert/) {
>              return ("RUST_UNWRAP", "...");
>          }
>      }
>      return ();
> }
> 
> Scenarios:
> 
> --- a/rust/kernel/alloc/kvec.rs
> +++ b/rust/kernel/alloc/kvec.rs
> @@ -42,6 +42,7 @@
>       pub fn new_with_data() -> Self {
> -        let x = Some(1);
> +        // Scenario 1: Production code (SHOULD WARN)
> +        let val = some_kernel_function().unwrap();
>           Vec { ptr: NonNull::dangling(), len: 0 }
>       }
>   
> @@ -150,6 +151,13 @@
> +    // Scenario 2: Explicitly justified (SHOULD NOT WARN)
> +    pub fn proof_of_concept() {
> +        let x = core::ptr::NonNull::new(ptr).unwrap(); // PANIC: ptr is never null here
> +    }
> +
> +    // Scenario 3: Already a comment (SHOULD NOT WARN)
> +    // let x = something.unwrap();
> +
> @@ -200,10 +208,20 @@
> +#[test]
> +fn scenario_4_standalone_test() {
> +    // SHOULD NOT WARN because of #[test] above
> +    let v: KVec<u32> = KVec::with_capacity(1, GFP_KERNEL).unwrap();
> +}
> +
> +#[macros::kunit_tests(rust_kvec)]
> +mod tests {
> +    use super::*;
> +
> +    fn test_internal_logic() {
> +        // Scenario 5: Inside KUnit mod (SHOULD NOT WARN)
> +        // Dirk's specific 21 warnings happened in a block like this.
> +        let mut v = KVec::new();
> +        v.push(1, GFP_KERNEL).unwrap();
> +        assert_eq!(v.pop().unwrap(), 1);
> +    }
> +}
> 
> If this looks okay, I can resubmit the patch series with this.
> 
> Best regards,
> Jason

Re: [PATCH v9 0/2] modularize Rust lints and add RUST_UNWRAP check

[Dirk Behme]

Hi Jason and Miguel,

On 07.02.26 23:49, Jason Hall wrote:
...
> The second patch introduces the  RUST_UNWRAP lint, which warns against
> the use of .unwrap() and .expect() unless they are accompanied by a 
> '// PANIC:' justification comment.

While some further thinking about the discussion in this thread I'm
under the impression that going this way somehow leaves us unhappy.
Either it becomes complicated (again, many thanks to Jason for working
on this!) or we will end up with several limitations and (confusing?)
false positives.

I wonder if it would be an option to change the strategy here?

In the last time we have introduced several rules by "convention".
Without checkpatch or lint support. Like "please use vertical style
for imports", "please use `__rust_helper` for helpers" or "please drop
`as_ref` from dev_* prints". Would it be an (easier?) option to go the
same way here? Instead of enforcing it with checkpatch?

I'm thinking about the same approach like we did with the examples
above: We identify the "wrong" `unwrap()` usages in the existing code
and "fix" them with patches. What would result in a clean code base.
At the same time it will give developers an indication that the
remaining ones are "allowed" ones which are ok. And for new code in
the review we ask for corrections if we spot a "wrong" usage.

Best regards

Dirk

Re: [PATCH v9 0/2] modularize Rust lints and add RUST_UNWRAP check

[Miguel Ojeda]

On Sat, Feb 14, 2026 at 7:11 AM Dirk Behme <dirk.behme@gmail.com> wrote:
>
> In the last time we have introduced several rules by "convention".
> Without checkpatch or lint support. Like "please use vertical style
> for imports", "please use `__rust_helper` for helpers" or "please drop
> `as_ref` from dev_* prints". Would it be an (easier?) option to go the
> same way here? Instead of enforcing it with checkpatch?
>
> I'm thinking about the same approach like we did with the examples
> above: We identify the "wrong" `unwrap()` usages in the existing code
> and "fix" them with patches. What would result in a clean code base.
> At the same time it will give developers an indication that the
> remaining ones are "allowed" ones which are ok. And for new code in
> the review we ask for corrections if we spot a "wrong" usage.

[ To give some context, in case it helps further discussion... ]

Yeah, that is the status quo, i.e. catching it during review
(depending on whether it is an acceptable case or not etc.).

However, there were concerns that now that more and more Rust is
getting into the kernel, with more contributors and subsystems
participating at the same time, we would eventually see `unwrap()`s
and so on proliferating here and there, i.e. that things would slip
through.

So after some discussion, we settled on asking for the Clippy lint
upstream plus a `checkpatch.pl` warning meanwhile / on top of. Thus I
filled the respective issues:

  https://github.com/Rust-for-Linux/linux/issues/1191
  https://github.com/rust-lang/rust-clippy/issues/15895 (switched to
Alejandra's earlier
https://github.com/rust-lang/rust-clippy/issues/15861).
  https://github.com/rust-lang/rust-clippy/issues/15896

The Clippy one would be the end goal, if we can get it to work well,
while `checkpatch.pl` would serve a similar role to the C side warning
for `BUG_ON()` (and friends).

Cheers,
Miguel

Re: [PATCH v9 0/2] modularize Rust lints and add RUST_UNWRAP check

[Miguel Ojeda]

On Sun, Feb 15, 2026 at 12:30 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> [ To give some context, in case it helps further discussion... ]

Fixing Danilo's email address so that he gets the ping, since he was
one of the ones that supported the lint.

Jason: please fix it in your contacts (or similar) for future patches :)

Cheers,
Miguel