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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <a798e6a368639f7a1ce633a6dfecd088d6ed4123.camel@perches.com>
Date: Wed, 04 Feb 2026 11:08:22 -0800
From: Joe Perches <joe@...ches.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Dirk Behme
	 <dirk.behme@...il.com>
Cc: Gary Guo <gary@...yguo.net>, Onur Özkan
	 <work@...rozkan.dev>, Jkhall81 <jason.kei.hall@...il.com>, 
	dirk.behme@...bosch.com, ojeda@...nel.org, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4] scripts: checkpatch: warn on Rust panicking methods

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@...il.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;