mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®