[<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