linux-kernel - Re: linux-next: build failure after merge of the rust tree

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: <CAJ-ks9kd4kOXDLfpqWr5vRj4WPvXbVfbrjbro=MQ0iFfyHNPyQ@mail.gmail.com>
Date: Tue, 24 Jun 2025 05:29:21 -0700
From: Tamir Duberstein <tamird@...il.com>
To: Alexandre Courbot <acourbot@...dia.com>
Cc: Danilo Krummrich <dakr@...nel.org>, Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, 
	Stephen Rothwell <sfr@...b.auug.org.au>, Lyude Paul <lyude@...hat.com>, 
	Andreas Hindborg <a.hindborg@...nel.org>, FUJITA Tomonori <fujita.tomonori@...il.com>, 
	Miguel Ojeda <ojeda@...nel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, 
	Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the rust tree

On Tue, Jun 24, 2025 at 5:24 AM Alexandre Courbot <acourbot@...dia.com> wrote:
>
> On Tue Jun 24, 2025 at 9:16 PM JST, Tamir Duberstein wrote:
> > On Tue, Jun 24, 2025 at 5:14 AM Alexandre Courbot <acourbot@...dia.com> wrote:
> >>
> >> On Tue Jun 24, 2025 at 9:00 PM JST, Danilo Krummrich wrote:
> >> > On Tue, Jun 24, 2025 at 12:31:52PM +0200, Miguel Ojeda wrote:
> >> >> On Tue, Jun 24, 2025 at 9:31 AM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> >> >> >
> >> >> > error[E0277]: the trait bound `u32: From<DmaTrfCmdSize>` is not satisfied
> >> >>
> >> >> > error[E0599]: no method named `as_nanos` found for struct `Delta` in the current scope
> >> >>
> >> >> > Presumably caused by commit
> >> >> >
> >> >> >   b7c8d7a8d251 ("rust: enable `clippy::cast_lossless` lint")
> >> >>
> >> >> The first error, yes -- the `register!` macro was changed to use
> >> >> `u32::from()` to avoid an `as` cast in that commit, and while the cast
> >> >> is OK converting the new `enum`s like `FalconCoreRev`, `from()`
> >> >> isn't`, so we would need to implement `From` explicitly -- Cc'ing
> >> >> Danilo, Alexandre, Lyude.
> >> >
> >> > It's a bit annoying to implement From explicitly for all of them, but it seems
> >> > to be the correct thing to do.
> >>
> >> This might be something `FromPrimitive` will help with eventually, but
> >> in the meantime I agree having explicit implementations is a bit
> >> cumbersome.
> >>
> >> What I don't understand is why these `as` are problematic - a type like
> >> `FalconCoreRev` is `repr(u8)`, so the cast cannot be lossy. I think this
> >> is the case for all such instances using the register!() macro.
> >
> > The use of `as` is problematic because it disempowers the compiler
> > from checking that the cast is not lossy. In other words, it is of
> > course fine in the case of a `repr(u8)` enum, but if the type changes
> > in a way that causes a lossy conversion, the compiler will not warn
> > you.
>
> I understand and agree with this, but why doesn't the linter limit
> itself to such lossy cases (e.g. `u64 as u32`) and let the harmless ones
> be?

Ah, that's a different lint. They are all explained in the docs
probably better than I can:

https://rust-lang.github.io/rust-clippy/master/index.html#cast_lossless
https://rust-lang.github.io/rust-clippy/master/index.html#cast_possible_truncation
https://rust-lang.github.io/rust-clippy/master/index.html#cast_possible_wrap
https://rust-lang.github.io/rust-clippy/master/index.html#cast_sign_loss

They are all allow-by-default though, because it is expected that
*sometimes* you do want to do the lossy thing and there's no other way
to express that.