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: <CANiq72mERwbmXYq-pi=WUAZ_VYGcBVS7tzH4P5zSUVCMcL4-CQ@mail.gmail.com>
Date: Wed, 2 Apr 2025 22:29:26 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Tamir Duberstein <tamird@...il.com>
Cc: Benno Lossin <benno.lossin@...ton.me>, Miguel Ojeda <ojeda@...nel.org>, 
	Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>, 
	Gary Guo <gary@...yguo.net>, Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, 
	Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org, patches@...ts.linux.dev
Subject: Re: [PATCH] rust: clean Rust 1.86.0 new `clippy::needless_continue` cases

On Wed, Apr 2, 2025 at 6:41 PM Tamir Duberstein <tamird@...il.com> wrote:
>
> The counterfactual is hard to prove - you don't know what true
> positives the lint would catch. In my opinion disabling lints is
> risking throwing the baby out with the bathwater.

It is true that it is not easy to know what we will exactly lose right
now (apart from what it claims in the docs and its examples), but one
can easily test enabling it in a couple cycles and we would have some
data from kernel code.

To be clear, disabling now does not mean forever -- we can reevaluate
with that data and possible improvements to the lint that happened
meanwhile (sometimes they get improved or split due to feedback).

By the way, the lint is in "pedantic" in Clippy and disabled by
default -- so we are "only" disabling w.r.t. what we do nowadays.

In any case, my main concern is cost: we already require a lot from
Rust kernel developers, typically more than in C, and while one goal
of the project is trying to see how far we can go on being strict
about things like lints, I worry we may overdo it at times.

Cheers,
Miguel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ