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: <2b83962d-0d1d-428d-8122-da25d4cd1af5@de.bosch.com>
Date: Mon, 9 Feb 2026 09:52:10 +0100
From: Dirk Behme <dirk.behme@...bosch.com>
To: Jason Hall <jason.kei.hall@...il.com>, 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

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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ