From: Jason Hall <jason.kei.hall@gmail.com>
To: Dirk Behme <dirk.behme@gmail.com>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v9 2/2] scripts: checkpatch: add RUST_UNWRAP lint
Date: Sun, 8 Feb 2026 07:01:10 -0700 [thread overview]
Message-ID: <20260208140110.258311-1-jason.kei.hall@gmail.com> (raw)
In-Reply-To: <9ecadaa2-0f6b-411f-9faf-0ecc93b26bc2@gmail.com>
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
next prev parent reply other threads:[~2026-02-08 14:01 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-01 15:57 [PATCH] scripts: checkpatch: warn on Rust panicking methods Jason Hall
2026-02-01 17:19 ` Charalampos Mitrodimas
2026-02-01 18:30 ` [PATCH v2] " Jason Hall
2026-02-01 19:37 ` Joe Perches
2026-02-01 19:57 ` [PATCH v3] " Jason Hall
2026-02-02 5:38 ` Dirk Behme
2026-02-02 13:56 ` [PATCH v4] " Jason Hall
2026-02-03 6:21 ` Dirk Behme
2026-02-03 15:25 ` Jkhall81
2026-02-03 15:49 ` Onur Özkan
2026-02-03 16:02 ` Gary Guo
2026-02-03 16:32 ` Onur Özkan
2026-02-03 16:54 ` Gary Guo
2026-02-04 15:56 ` Dirk Behme
2026-02-04 18:10 ` Miguel Ojeda
2026-02-04 19:08 ` Joe Perches
2026-02-05 1:42 ` [PATCH v5] scripts: checkpatch: move Rust-specific lints to separate file Jason Hall
2026-02-05 20:55 ` Miguel Ojeda
2026-02-06 8:31 ` Dirk Behme
2026-02-06 17:41 ` Miguel Ojeda
2026-02-07 15:56 ` [PATCH v6] " Jason Hall
2026-02-07 16:07 ` Miguel Ojeda
2026-02-07 16:53 ` [PATCH v7] " Jason Hall
2026-02-07 18:46 ` Miguel Ojeda
2026-02-07 21:07 ` [PATCH v8 0/2] modularize Rust lints and add RUST_UNWRAP check Jason Hall
2026-02-07 21:07 ` [PATCH v8 1/2] scripts: checkpatch: move Rust-specific lints to separate file Jason Hall
2026-02-07 21:53 ` Miguel Ojeda
2026-02-07 22:49 ` [PATCH v9 0/2] modularize Rust lints and add RUST_UNWRAP check Jason Hall
2026-02-07 22:49 ` [PATCH v9 1/2] scripts: checkpatch: move Rust-specific lints to separate file Jason Hall
2026-02-07 22:49 ` [PATCH v9 2/2] scripts: checkpatch: add RUST_UNWRAP lint Jason Hall
2026-02-08 7:55 ` Dirk Behme
2026-02-08 14:01 ` Jason Hall [this message]
2026-02-09 8:52 ` Dirk Behme
2026-02-08 6:43 ` [PATCH v9 0/2] modularize Rust lints and add RUST_UNWRAP check Greg KH
2026-02-14 6:11 ` Dirk Behme
2026-02-14 23:30 ` Miguel Ojeda
2026-02-14 23:32 ` Miguel Ojeda
2026-02-07 21:07 ` [PATCH v8 2/2] scripts: checkpatch: add RUST_UNWRAP lint Jason Hall
2026-02-05 13:23 ` [PATCH v4] scripts: checkpatch: warn on Rust panicking methods Dirk Behme
2026-02-05 21:00 ` Miguel Ojeda
2026-02-04 18:11 ` Miguel Ojeda
2026-02-01 19:51 ` [PATCH] " Gary Guo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260208140110.258311-1-jason.kei.hall@gmail.com \
--to=jason.kei.hall@gmail.com \
--cc=dirk.behme@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=rust-for-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®