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-ks9m-pas1nYSr7GKvREsOKdGOoyW2ru3OKnnjerv9hsWdGw@mail.gmail.com>
Date: Tue, 24 Jun 2025 05:16:53 -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: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.

>
> >
> > nova-next also contains a couple of cases where the introduction of
> > `cast_lossless` causes warnings.
> >
> > I can implement the From traits and fix up the warnings caused by enabling
> > `cast_lossless` in my tree with subsequent patches, such that we do not have to
> > carry all this as merge resolution.
>
> Let me know if you want me to take care of that.