linux-kernel - Re: [PATCH v3 3/3] rust: remove `#[allow(clippy::non_send_fields_in_send

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72mDJTOwVNOdaWOtJk+O2JFu-RGYHnSLTwDrWu352pRYAA@mail.gmail.com>
Date: Sat, 28 Jun 2025 15:37:57 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Onur <work@...rozkan.dev>
Cc: viresh.kumar@...aro.org, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org, 
	linux-kselftest@...r.kernel.org, kunit-dev@...glegroups.com, 
	airlied@...il.com, simona@...ll.ch, ojeda@...nel.org, alex.gaynor@...il.com, 
	boqun.feng@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com, 
	lossin@...nel.org, a.hindborg@...nel.org, aliceryhl@...gle.com, 
	tmgross@...ch.edu, rafael@...nel.org, gregkh@...uxfoundation.org, 
	maarten.lankhorst@...ux.intel.com, mripard@...nel.org, tzimmermann@...e.de, 
	davidgow@...gle.com, nm@...com
Subject: Re: [PATCH v3 3/3] rust: remove `#[allow(clippy::non_send_fields_in_send_ty)]`

On Sat, Jun 28, 2025 at 3:04 PM Onur <work@...rozkan.dev> wrote:
>
> Yeah, I meant that it't taking more effort than it should, like digging
> through historical changes in the relevant parts of the source code,
> trying to figuring out whether it was just a false positive or if there
> was a specific reason behind it, etc.

Yeah, that is a big part of kernel development, especially on the
maintenance side :)

I definitely agree that a good comment in the source code is better
than going through Git history, and the kernel sometimes has had some
things documented in the Git log that should have been in the source
code instead. It happens.

However, in some cases like this one it is not clear it would help.
For instance, here the lint reason message could have been something
that made sense back then when the lint was enabled, and yet we would
still have had to notice the lint got disabled later on, so we would
end up still going into the Git log.

`expect` is great to mitigate some of that -- sadly we cannot use it
as much as we would like due to sometimes being conditional to an arch
or the kernel config or the Rust version. (And your first patch may
have some cases that perhaps we cannot convert due to that -- I didn't
check)

Cheers,
Miguel