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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ