Re: [PATCH v5 0/6] rust: reduce pointer casts, enable related lints

[Tamir Duberstein <tamird@gmail.com>]

On Mon, Mar 24, 2025 at 5:55 PM Benno Lossin <benno.lossin@proton.me> wrote:
>
> On Mon Mar 24, 2025 at 9:55 PM CET, Tamir Duberstein wrote:
> > On Mon, Mar 24, 2025 at 4:16 PM Benno Lossin <benno.lossin@proton.me> wrote:
> >> * `shared_ref as *const _` (for example in rust/kernel/uaccess.rs:247,
> >>   rust/kernel/str.rs:32 and rust/kernel/fs/file.rs:367), these we can
> >>   replace with `let ptr: *const ... = shared_ref;`. Don't know if there
> >>   is a clippy lint for this.
> >
> > I think there's not a focused one. There's a nuclear option:
> > https://rust-lang.github.io/rust-clippy/master/index.html?levels=allow#as_conversions
>
> Yeah I saw that one, I don't think it's a good idea, since there will be
> false positives.
>
> >> * some pointer casts in rust/kernel/list/impl_list_item_mod.rs:{253,254}
> >>   not sure if they can be converted though (maybe they are unsizing the
> >>   pointer?)
> >
> > I have a local series that gets rid of these by doing similar things
> > to https://lore.kernel.org/all/20250307-no-offset-v1-0-0c728f63b69c@gmail.com/.
> > I can send it later this week but it probably can't land until Alice
> > is back from vacation; she was the author of this code.
>
> No worries, as I wrote below, I think it's fine to do that in a new
> series.
>
> >>   Another pointer cast in rust/kernel/driver.rs:81 (I'm pretty sure this
> >>   one can be replaced by a `.cast()`)
> >>
> >> Some clippy lints that we could also enable that share the spirit of
> >> this series:
> >>
> >> * `char_lit_as_u8` (maybe that also covers the `'|' as u32` case from
> >>   above?)
> >
> > It's already enabled, it's warn-by-default.
>
> Ah I see, didn't look :)
>
> >> * `cast_lossless` (maybe this catches some of the `num as int_type`
> >>   conversions I mentioned above)
> >
> > Yeah, suggested the same above. I had hoped this would deal with the
> > char as u32 pattern but it did not.
>
> Aw that's a shame. Maybe we should create a clippy issue for that,
> thoughts?

Yeah, it's not clear to me why it isn't covered by `cast_lossless`.
Might just be a bug. Want to file it?

>
> >> I'll leave it up to you what you want to do with this: add it to this
> >> series, make a new one, or let someone else handle it. If you don't want
> >> to handle it, let me know, then I'll create a good-first-issue :)
> >
> > I'll add a patch for `cast_lossless` -- the rest should probably go
> > into an issue.
>
> Do you mind filing the issue? Then you can decide yourself what you want
> to do yourself vs what you want to leave for others. Feel free to copy
> from my mail summary.

Well, I don't really know what's left to do. We're pretty close at
this point to having enabled everything but the nukes. Then there's
the strict provenance thing, which I suppose we can write down.

> Also I wouldn't mark it as a good-first-issue yet, since it's pretty
> complicated and needs to be delayed/based on this series.

Yeah, certainly not good-first-issue.