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: <20260208140110.258311-1-jason.kei.hall@gmail.com>
Date: Sun,  8 Feb 2026 07:01:10 -0700
From: Jason Hall <jason.kei.hall@...il.com>
To: Dirk Behme <dirk.behme@...il.com>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	rust-for-linux@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v9 2/2] scripts: checkpatch: add RUST_UNWRAP lint

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ