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: <CANiq72kgB6gQ3+etQOYLLDqWt4EQhiDfN3dcwHBOpZh9USt3iA@mail.gmail.com>
Date: Sat, 28 Jun 2025 15:28:29 +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:11 PM Onur <work@...rozkan.dev> wrote:
>
> Aha, I see. I missed that. I guess `allow` was added when the author
> had this lint enabled on their checkout, but their work was merged when
> lint removal was merged before that.

Yeah, some of the code going around was written years ago, so
sometimes this sort of thing happens. :)

> Do you want me to update the patch description by including
> 5e7c9b84ad08 ref and send v4?

Sure -- maybe wait a few days, to see if anyone says anything else.
Then we will need to wait for Acked-bys from other maintainers.

Or, actually, if you are sending a new version and you are willing to
do it, then it would be easier to land if you split the first patch
also by subsystem -- that way each maintainer can take their patches
on their own time instead. Since each patch is independent, you can
send them in independent patch series, that makes it even easier for
maintainers to track.

For instance, you could do this grouping:

     rust/kernel/error.rs                | 2 +-
     rust/kernel/types.rs                | 2 +-
     rust/macros/helpers.rs              | 2 +-
     (+ this patch #2)

     rust/kernel/init.rs                 | 6 +++---

     rust/kernel/kunit.rs                | 2 +-

     drivers/gpu/nova-core/regs.rs       | 2 +-
     rust/kernel/drm/ioctl.rs            | 8 ++++----

     rust/kernel/devres.rs               | 2 +-
     rust/kernel/driver.rs               | 2 +-

     rust/kernel/alloc/allocator_test.rs | 2 +-

     rust/kernel/opp.rs                  | 4 ++--
     (+ this patch #3)

So e.g. the top one (Rust) would be a series of 2 patches, then the
next one (pin-init) a single independent patch, and so on.

> Sorry for misunderstanding by the way!

No worries at all! It happens :)

And thanks for doing these cleanups! They are appreciated.

Cheers,
Miguel