| Message ID | 20250325-ptr-as-ptr-v7-0-87ab452147b9@gmail.com |
|---|---|
| Headers | show |
| Series | rust: reduce `as` casts, enable related lints | expand |
On Tue, Mar 25, 2025 at 9:07 PM Tamir Duberstein <tamird@gmail.com> wrote: > > Changes in v7: > - Add patch to enable `clippy::ref_as_ptr`. > - Link to v6: https://lore.kernel.org/r/20250324-ptr-as-ptr-v6-0-49d1b7fd4290@gmail.com Please slow down -- at least wait a few days between revisions (unless there is a particular reason that requires it, of course). We are in the merge window anyway, so there is no urgency to resend since these cannot go in, and you may want to rebase on top of -rc1 when it gets released so that you can cover most/all cases added by then. Thanks! Cheers, Miguel
On Tue, Mar 25, 2025 at 6:11 PM Benno Lossin <benno.lossin@proton.me> wrote: > > On Tue Mar 25, 2025 at 9:07 PM CET, Tamir Duberstein wrote: > > diff --git a/rust/kernel/str.rs b/rust/kernel/str.rs > > index 40034f77fc2f..6233af50bab7 100644 > > --- a/rust/kernel/str.rs > > +++ b/rust/kernel/str.rs > > @@ -29,7 +29,7 @@ pub const fn is_empty(&self) -> bool { > > #[inline] > > pub const fn from_bytes(bytes: &[u8]) -> &Self { > > // SAFETY: `BStr` is transparent to `[u8]`. > > - unsafe { &*(bytes as *const [u8] as *const BStr) } > > + unsafe { &*(core::mem::transmute::<*const [u8], *const Self>(bytes)) } > > Hmm I'm not sure about using `transmute` here. Yes the types are > transparent, but I don't think that we should use it here. What's your suggestion? I initially tried let bytes: *const [u8] = bytes; unsafe { &*bytes.cast() } but that doesn't compile because of the implicit Sized bound on pointer::cast. > > > } > > > > /// Strip a prefix from `self`. Delegates to [`slice::strip_prefix`]. > > @@ -290,7 +290,7 @@ pub const fn from_bytes_with_nul(bytes: &[u8]) -> Result<&Self, CStrConvertError > > #[inline] > > pub unsafe fn from_bytes_with_nul_unchecked_mut(bytes: &mut [u8]) -> &mut CStr { > > // SAFETY: Properties of `bytes` guaranteed by the safety precondition. > > - unsafe { &mut *(bytes as *mut [u8] as *mut CStr) } > > + unsafe { &mut *(core::mem::transmute::<*mut [u8], *mut Self>(bytes)) } > > } > > > > /// Returns a C pointer to the string. > > diff --git a/rust/kernel/uaccess.rs b/rust/kernel/uaccess.rs > > index 80a9782b1c6e..c042b1fe499e 100644 > > --- a/rust/kernel/uaccess.rs > > +++ b/rust/kernel/uaccess.rs > > @@ -242,7 +242,7 @@ pub fn read_raw(&mut self, out: &mut [MaybeUninit<u8>]) -> Result { > > pub fn read_slice(&mut self, out: &mut [u8]) -> Result { > > // SAFETY: The types are compatible and `read_raw` doesn't write uninitialized bytes to > > // `out`. > > - let out = unsafe { &mut *(out as *mut [u8] as *mut [MaybeUninit<u8>]) }; > > + let out = unsafe { &mut *(core::mem::transmute::<*mut [u8], *mut [MaybeUninit<u8>]>(out)) }; > > I have a patch that adds a `cast_slice_mut` method that could be used > here, so I can fix it in that series. But let's not use `transmute` here > either. See above - I don't know what else I could write here.
On Tue Mar 25, 2025 at 11:33 PM CET, Tamir Duberstein wrote: > On Tue, Mar 25, 2025 at 6:11 PM Benno Lossin <benno.lossin@proton.me> wrote: >> >> On Tue Mar 25, 2025 at 9:07 PM CET, Tamir Duberstein wrote: >> > diff --git a/rust/kernel/str.rs b/rust/kernel/str.rs >> > index 40034f77fc2f..6233af50bab7 100644 >> > --- a/rust/kernel/str.rs >> > +++ b/rust/kernel/str.rs >> > @@ -29,7 +29,7 @@ pub const fn is_empty(&self) -> bool { >> > #[inline] >> > pub const fn from_bytes(bytes: &[u8]) -> &Self { >> > // SAFETY: `BStr` is transparent to `[u8]`. >> > - unsafe { &*(bytes as *const [u8] as *const BStr) } >> > + unsafe { &*(core::mem::transmute::<*const [u8], *const Self>(bytes)) } >> >> Hmm I'm not sure about using `transmute` here. Yes the types are >> transparent, but I don't think that we should use it here. > > What's your suggestion? I initially tried > > let bytes: *const [u8] = bytes; > unsafe { &*bytes.cast() } > > but that doesn't compile because of the implicit Sized bound on pointer::cast. This is AFAIK one of the only places where we cannot get rid of the `as` cast. So: let bytes: *const [u8] = bytes; // CAST: `BStr` transparently wraps `[u8]`. let bytes = bytes as *const BStr; // SAFETY: `bytes` is derived from a reference. unsafe { &*bytes } IMO a `transmute` is worse than an `as` cast :) --- Cheers, Benno
On Tue, Mar 25, 2025 at 4:23 PM Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote: > > On Tue, Mar 25, 2025 at 9:07 PM Tamir Duberstein <tamird@gmail.com> wrote: > > > > Changes in v7: > > - Add patch to enable `clippy::ref_as_ptr`. > > - Link to v6: https://lore.kernel.org/r/20250324-ptr-as-ptr-v6-0-49d1b7fd4290@gmail.com > > Please slow down -- at least wait a few days between revisions (unless > there is a particular reason that requires it, of course). Thanks, certainly no urgency here. In this particular case this isn't a true revision: the difference between v7 and v6 is the presence of an additional patch. > We are in the merge window anyway, so there is no urgency to resend > since these cannot go in, and you may want to rebase on top of -rc1 > when it gets released so that you can cover most/all cases added by > then. While it's true that this won't be picked up for some time (and that's ok), I wanted to get Benno's eyes on it sooner than later. Is there a workflow (within the mailing list) for such a case, or do folks go out of band in this situation? Thanks! Tamir
On Tue, Mar 25, 2025 at 6:40 PM Benno Lossin <benno.lossin@proton.me> wrote: > > On Tue Mar 25, 2025 at 11:33 PM CET, Tamir Duberstein wrote: > > On Tue, Mar 25, 2025 at 6:11 PM Benno Lossin <benno.lossin@proton.me> wrote: > >> > >> On Tue Mar 25, 2025 at 9:07 PM CET, Tamir Duberstein wrote: > >> > diff --git a/rust/kernel/str.rs b/rust/kernel/str.rs > >> > index 40034f77fc2f..6233af50bab7 100644 > >> > --- a/rust/kernel/str.rs > >> > +++ b/rust/kernel/str.rs > >> > @@ -29,7 +29,7 @@ pub const fn is_empty(&self) -> bool { > >> > #[inline] > >> > pub const fn from_bytes(bytes: &[u8]) -> &Self { > >> > // SAFETY: `BStr` is transparent to `[u8]`. > >> > - unsafe { &*(bytes as *const [u8] as *const BStr) } > >> > + unsafe { &*(core::mem::transmute::<*const [u8], *const Self>(bytes)) } > >> > >> Hmm I'm not sure about using `transmute` here. Yes the types are > >> transparent, but I don't think that we should use it here. > > > > What's your suggestion? I initially tried > > > > let bytes: *const [u8] = bytes; > > unsafe { &*bytes.cast() } > > > > but that doesn't compile because of the implicit Sized bound on pointer::cast. > > This is AFAIK one of the only places where we cannot get rid of the `as` > cast. So: > > let bytes: *const [u8] = bytes; > // CAST: `BStr` transparently wraps `[u8]`. > let bytes = bytes as *const BStr; > // SAFETY: `bytes` is derived from a reference. > unsafe { &*bytes } > > IMO a `transmute` is worse than an `as` cast :) Hmm, looking at this again we can just transmute ref-to-ref and avoid pointers entirely. We're already doing that in `CStr::from_bytes_with_nul_unchecked` Why is transmute worse than an `as` cast?
On Wed Mar 26, 2025 at 12:54 AM CET, Tamir Duberstein wrote: > On Tue, Mar 25, 2025 at 6:40 PM Benno Lossin <benno.lossin@proton.me> wrote: >> On Tue Mar 25, 2025 at 11:33 PM CET, Tamir Duberstein wrote: >> > On Tue, Mar 25, 2025 at 6:11 PM Benno Lossin <benno.lossin@proton.me> wrote: >> >> On Tue Mar 25, 2025 at 9:07 PM CET, Tamir Duberstein wrote: >> >> > diff --git a/rust/kernel/str.rs b/rust/kernel/str.rs >> >> > index 40034f77fc2f..6233af50bab7 100644 >> >> > --- a/rust/kernel/str.rs >> >> > +++ b/rust/kernel/str.rs >> >> > @@ -29,7 +29,7 @@ pub const fn is_empty(&self) -> bool { >> >> > #[inline] >> >> > pub const fn from_bytes(bytes: &[u8]) -> &Self { >> >> > // SAFETY: `BStr` is transparent to `[u8]`. >> >> > - unsafe { &*(bytes as *const [u8] as *const BStr) } >> >> > + unsafe { &*(core::mem::transmute::<*const [u8], *const Self>(bytes)) } >> >> >> >> Hmm I'm not sure about using `transmute` here. Yes the types are >> >> transparent, but I don't think that we should use it here. >> > >> > What's your suggestion? I initially tried >> > >> > let bytes: *const [u8] = bytes; >> > unsafe { &*bytes.cast() } >> > >> > but that doesn't compile because of the implicit Sized bound on pointer::cast. >> >> This is AFAIK one of the only places where we cannot get rid of the `as` >> cast. So: >> >> let bytes: *const [u8] = bytes; >> // CAST: `BStr` transparently wraps `[u8]`. >> let bytes = bytes as *const BStr; >> // SAFETY: `bytes` is derived from a reference. >> unsafe { &*bytes } >> >> IMO a `transmute` is worse than an `as` cast :) > > Hmm, looking at this again we can just transmute ref-to-ref and avoid > pointers entirely. We're already doing that in > `CStr::from_bytes_with_nul_unchecked` > > Why is transmute worse than an `as` cast? It's right in the docs: "`transmute` should be the absolute last resort." [1]. IIRC, Gary was a bit more lenient in its use, but I think we should avoid it as much as possible such that people copying code or taking inspiration also don't use it. So for both cases I'd prefer an `as` cast. [1]: https://doc.rust-lang.org/std/mem/fn.transmute.html --- Cheers, Benno
On Wed, Mar 26, 2025 at 6:31 AM Benno Lossin <benno.lossin@proton.me> wrote: > > On Wed Mar 26, 2025 at 12:54 AM CET, Tamir Duberstein wrote: > > On Tue, Mar 25, 2025 at 6:40 PM Benno Lossin <benno.lossin@proton.me> wrote: > >> On Tue Mar 25, 2025 at 11:33 PM CET, Tamir Duberstein wrote: > >> > On Tue, Mar 25, 2025 at 6:11 PM Benno Lossin <benno.lossin@proton.me> wrote: > >> >> On Tue Mar 25, 2025 at 9:07 PM CET, Tamir Duberstein wrote: > >> >> > diff --git a/rust/kernel/str.rs b/rust/kernel/str.rs > >> >> > index 40034f77fc2f..6233af50bab7 100644 > >> >> > --- a/rust/kernel/str.rs > >> >> > +++ b/rust/kernel/str.rs > >> >> > @@ -29,7 +29,7 @@ pub const fn is_empty(&self) -> bool { > >> >> > #[inline] > >> >> > pub const fn from_bytes(bytes: &[u8]) -> &Self { > >> >> > // SAFETY: `BStr` is transparent to `[u8]`. > >> >> > - unsafe { &*(bytes as *const [u8] as *const BStr) } > >> >> > + unsafe { &*(core::mem::transmute::<*const [u8], *const Self>(bytes)) } > >> >> > >> >> Hmm I'm not sure about using `transmute` here. Yes the types are > >> >> transparent, but I don't think that we should use it here. > >> > > >> > What's your suggestion? I initially tried > >> > > >> > let bytes: *const [u8] = bytes; > >> > unsafe { &*bytes.cast() } > >> > > >> > but that doesn't compile because of the implicit Sized bound on pointer::cast. > >> > >> This is AFAIK one of the only places where we cannot get rid of the `as` > >> cast. So: > >> > >> let bytes: *const [u8] = bytes; > >> // CAST: `BStr` transparently wraps `[u8]`. > >> let bytes = bytes as *const BStr; > >> // SAFETY: `bytes` is derived from a reference. > >> unsafe { &*bytes } > >> > >> IMO a `transmute` is worse than an `as` cast :) > > > > Hmm, looking at this again we can just transmute ref-to-ref and avoid > > pointers entirely. We're already doing that in > > `CStr::from_bytes_with_nul_unchecked` > > > > Why is transmute worse than an `as` cast? > > It's right in the docs: "`transmute` should be the absolute last > resort." [1]. IIRC, Gary was a bit more lenient in its use, but I think > we should avoid it as much as possible such that people copying code or > taking inspiration also don't use it. > > So for both cases I'd prefer an `as` cast. > > [1]: https://doc.rust-lang.org/std/mem/fn.transmute.html I don't follow the logic. The trouble with `as` casts is that they are very lenient in what they allow, and to do these conversions with `as` casts requires ref -> pointer -> pointer -> pointer deref versus a single transmute. The safety comment perfectly describes why it's OK to do: the types are transparent. So why is `as` casting pointers better? It's just as unchecked as transmuting, and worse, it requires a raw pointer dereference.
On Wed Mar 26, 2025 at 11:35 AM CET, Tamir Duberstein wrote: > On Wed, Mar 26, 2025 at 6:31 AM Benno Lossin <benno.lossin@proton.me> wrote: >> On Wed Mar 26, 2025 at 12:54 AM CET, Tamir Duberstein wrote: >> > On Tue, Mar 25, 2025 at 6:40 PM Benno Lossin <benno.lossin@proton.me> wrote: >> >> On Tue Mar 25, 2025 at 11:33 PM CET, Tamir Duberstein wrote: >> >> > On Tue, Mar 25, 2025 at 6:11 PM Benno Lossin <benno.lossin@proton.me> wrote: >> >> >> On Tue Mar 25, 2025 at 9:07 PM CET, Tamir Duberstein wrote: >> >> >> > diff --git a/rust/kernel/str.rs b/rust/kernel/str.rs >> >> >> > index 40034f77fc2f..6233af50bab7 100644 >> >> >> > --- a/rust/kernel/str.rs >> >> >> > +++ b/rust/kernel/str.rs >> >> >> > @@ -29,7 +29,7 @@ pub const fn is_empty(&self) -> bool { >> >> >> > #[inline] >> >> >> > pub const fn from_bytes(bytes: &[u8]) -> &Self { >> >> >> > // SAFETY: `BStr` is transparent to `[u8]`. >> >> >> > - unsafe { &*(bytes as *const [u8] as *const BStr) } >> >> >> > + unsafe { &*(core::mem::transmute::<*const [u8], *const Self>(bytes)) } >> >> >> >> >> >> Hmm I'm not sure about using `transmute` here. Yes the types are >> >> >> transparent, but I don't think that we should use it here. >> >> > >> >> > What's your suggestion? I initially tried >> >> > >> >> > let bytes: *const [u8] = bytes; >> >> > unsafe { &*bytes.cast() } >> >> > >> >> > but that doesn't compile because of the implicit Sized bound on pointer::cast. >> >> >> >> This is AFAIK one of the only places where we cannot get rid of the `as` >> >> cast. So: >> >> >> >> let bytes: *const [u8] = bytes; >> >> // CAST: `BStr` transparently wraps `[u8]`. >> >> let bytes = bytes as *const BStr; >> >> // SAFETY: `bytes` is derived from a reference. >> >> unsafe { &*bytes } >> >> >> >> IMO a `transmute` is worse than an `as` cast :) >> > >> > Hmm, looking at this again we can just transmute ref-to-ref and avoid >> > pointers entirely. We're already doing that in >> > `CStr::from_bytes_with_nul_unchecked` >> > >> > Why is transmute worse than an `as` cast? >> >> It's right in the docs: "`transmute` should be the absolute last >> resort." [1]. IIRC, Gary was a bit more lenient in its use, but I think >> we should avoid it as much as possible such that people copying code or >> taking inspiration also don't use it. >> >> So for both cases I'd prefer an `as` cast. >> >> [1]: https://doc.rust-lang.org/std/mem/fn.transmute.html > > I don't follow the logic. The trouble with `as` casts is that they are > very lenient in what they allow, and to do these conversions with `as` > casts requires ref -> pointer -> pointer -> pointer deref versus a > single transmute. The safety comment perfectly describes why it's OK > to do: the types are transparent. So why is `as` casting pointers > better? It's just as unchecked as transmuting, and worse, it requires > a raw pointer dereference. Note that you're not transmuting `[u8]` to `BStr`, but `*const [u8]` to `*const BStr`. Those pointers have provenance and I'm not sure if transmuting them preserves it. I tried to find some existing issues about the topic and found that there exists a clippy lint `transmute_ptr_to_ptr`. There is an issue asking for a better justification [1] and it seems like nobody provided one there. Maybe we should ask the opsem team what happens to provenance when transmuting? [1]: https://github.com/rust-lang/rust-clippy/issues/6372 --- Cheers, Benno
On Wed, Mar 26, 2025 at 12:43 PM Benno Lossin <benno.lossin@proton.me> wrote: > > On Wed Mar 26, 2025 at 11:35 AM CET, Tamir Duberstein wrote: > > On Wed, Mar 26, 2025 at 6:31 AM Benno Lossin <benno.lossin@proton.me> wrote: > >> On Wed Mar 26, 2025 at 12:54 AM CET, Tamir Duberstein wrote: > >> > On Tue, Mar 25, 2025 at 6:40 PM Benno Lossin <benno.lossin@proton.me> wrote: > >> >> On Tue Mar 25, 2025 at 11:33 PM CET, Tamir Duberstein wrote: > >> >> > On Tue, Mar 25, 2025 at 6:11 PM Benno Lossin <benno.lossin@proton.me> wrote: > >> >> >> On Tue Mar 25, 2025 at 9:07 PM CET, Tamir Duberstein wrote: > >> >> >> > diff --git a/rust/kernel/str.rs b/rust/kernel/str.rs > >> >> >> > index 40034f77fc2f..6233af50bab7 100644 > >> >> >> > --- a/rust/kernel/str.rs > >> >> >> > +++ b/rust/kernel/str.rs > >> >> >> > @@ -29,7 +29,7 @@ pub const fn is_empty(&self) -> bool { > >> >> >> > #[inline] > >> >> >> > pub const fn from_bytes(bytes: &[u8]) -> &Self { > >> >> >> > // SAFETY: `BStr` is transparent to `[u8]`. > >> >> >> > - unsafe { &*(bytes as *const [u8] as *const BStr) } > >> >> >> > + unsafe { &*(core::mem::transmute::<*const [u8], *const Self>(bytes)) } > >> >> >> > >> >> >> Hmm I'm not sure about using `transmute` here. Yes the types are > >> >> >> transparent, but I don't think that we should use it here. > >> >> > > >> >> > What's your suggestion? I initially tried > >> >> > > >> >> > let bytes: *const [u8] = bytes; > >> >> > unsafe { &*bytes.cast() } > >> >> > > >> >> > but that doesn't compile because of the implicit Sized bound on pointer::cast. > >> >> > >> >> This is AFAIK one of the only places where we cannot get rid of the `as` > >> >> cast. So: > >> >> > >> >> let bytes: *const [u8] = bytes; > >> >> // CAST: `BStr` transparently wraps `[u8]`. > >> >> let bytes = bytes as *const BStr; > >> >> // SAFETY: `bytes` is derived from a reference. > >> >> unsafe { &*bytes } > >> >> > >> >> IMO a `transmute` is worse than an `as` cast :) > >> > > >> > Hmm, looking at this again we can just transmute ref-to-ref and avoid > >> > pointers entirely. We're already doing that in > >> > `CStr::from_bytes_with_nul_unchecked` > >> > > >> > Why is transmute worse than an `as` cast? > >> > >> It's right in the docs: "`transmute` should be the absolute last > >> resort." [1]. IIRC, Gary was a bit more lenient in its use, but I think > >> we should avoid it as much as possible such that people copying code or > >> taking inspiration also don't use it. > >> > >> So for both cases I'd prefer an `as` cast. > >> > >> [1]: https://doc.rust-lang.org/std/mem/fn.transmute.html > > > > I don't follow the logic. The trouble with `as` casts is that they are > > very lenient in what they allow, and to do these conversions with `as` > > casts requires ref -> pointer -> pointer -> pointer deref versus a > > single transmute. The safety comment perfectly describes why it's OK > > to do: the types are transparent. So why is `as` casting pointers > > better? It's just as unchecked as transmuting, and worse, it requires > > a raw pointer dereference. > > Note that you're not transmuting `[u8]` to `BStr`, but `*const [u8]` to > `*const BStr`. Those pointers have provenance and I'm not sure if > transmuting them preserves it. In the current code you're looking at, yes. But in the code I have locally I'm transmuting `[u8]` to `BStr`. See my earlier reply where I said "Hmm, looking at this again we can just transmute ref-to-ref and avoid pointers entirely. We're already doing that in `CStr::from_bytes_with_nul_unchecked`". > I tried to find some existing issues about the topic and found that > there exists a clippy lint `transmute_ptr_to_ptr`. There is an issue > asking for a better justification [1] and it seems like nobody provided > one there. Maybe we should ask the opsem team what happens to provenance > when transmuting? Yeah, we should do this - but again: not relevant in this discussion.
On Wed Mar 26, 2025 at 5:57 PM CET, Tamir Duberstein wrote: > On Wed, Mar 26, 2025 at 12:43 PM Benno Lossin <benno.lossin@proton.me> wrote: >> On Wed Mar 26, 2025 at 11:35 AM CET, Tamir Duberstein wrote: >> > On Wed, Mar 26, 2025 at 6:31 AM Benno Lossin <benno.lossin@proton.me> wrote: >> >> On Wed Mar 26, 2025 at 12:54 AM CET, Tamir Duberstein wrote: >> >> > On Tue, Mar 25, 2025 at 6:40 PM Benno Lossin <benno.lossin@proton.me> wrote: >> >> >> On Tue Mar 25, 2025 at 11:33 PM CET, Tamir Duberstein wrote: >> >> >> > On Tue, Mar 25, 2025 at 6:11 PM Benno Lossin <benno.lossin@proton.me> wrote: >> >> >> >> On Tue Mar 25, 2025 at 9:07 PM CET, Tamir Duberstein wrote: >> >> >> >> > diff --git a/rust/kernel/str.rs b/rust/kernel/str.rs >> >> >> >> > index 40034f77fc2f..6233af50bab7 100644 >> >> >> >> > --- a/rust/kernel/str.rs >> >> >> >> > +++ b/rust/kernel/str.rs >> >> >> >> > @@ -29,7 +29,7 @@ pub const fn is_empty(&self) -> bool { >> >> >> >> > #[inline] >> >> >> >> > pub const fn from_bytes(bytes: &[u8]) -> &Self { >> >> >> >> > // SAFETY: `BStr` is transparent to `[u8]`. >> >> >> >> > - unsafe { &*(bytes as *const [u8] as *const BStr) } >> >> >> >> > + unsafe { &*(core::mem::transmute::<*const [u8], *const Self>(bytes)) } >> >> >> >> >> >> >> >> Hmm I'm not sure about using `transmute` here. Yes the types are >> >> >> >> transparent, but I don't think that we should use it here. >> >> >> > >> >> >> > What's your suggestion? I initially tried >> >> >> > >> >> >> > let bytes: *const [u8] = bytes; >> >> >> > unsafe { &*bytes.cast() } >> >> >> > >> >> >> > but that doesn't compile because of the implicit Sized bound on pointer::cast. >> >> >> >> >> >> This is AFAIK one of the only places where we cannot get rid of the `as` >> >> >> cast. So: >> >> >> >> >> >> let bytes: *const [u8] = bytes; >> >> >> // CAST: `BStr` transparently wraps `[u8]`. >> >> >> let bytes = bytes as *const BStr; >> >> >> // SAFETY: `bytes` is derived from a reference. >> >> >> unsafe { &*bytes } >> >> >> >> >> >> IMO a `transmute` is worse than an `as` cast :) >> >> > >> >> > Hmm, looking at this again we can just transmute ref-to-ref and avoid >> >> > pointers entirely. We're already doing that in >> >> > `CStr::from_bytes_with_nul_unchecked` >> >> > >> >> > Why is transmute worse than an `as` cast? >> >> >> >> It's right in the docs: "`transmute` should be the absolute last >> >> resort." [1]. IIRC, Gary was a bit more lenient in its use, but I think >> >> we should avoid it as much as possible such that people copying code or >> >> taking inspiration also don't use it. >> >> >> >> So for both cases I'd prefer an `as` cast. >> >> >> >> [1]: https://doc.rust-lang.org/std/mem/fn.transmute.html >> > >> > I don't follow the logic. The trouble with `as` casts is that they are >> > very lenient in what they allow, and to do these conversions with `as` >> > casts requires ref -> pointer -> pointer -> pointer deref versus a >> > single transmute. The safety comment perfectly describes why it's OK >> > to do: the types are transparent. So why is `as` casting pointers >> > better? It's just as unchecked as transmuting, and worse, it requires >> > a raw pointer dereference. >> >> Note that you're not transmuting `[u8]` to `BStr`, but `*const [u8]` to >> `*const BStr`. Those pointers have provenance and I'm not sure if >> transmuting them preserves it. > > In the current code you're looking at, yes. But in the code I have > locally I'm transmuting `[u8]` to `BStr`. See my earlier reply where I > said "Hmm, looking at this again we can just transmute ref-to-ref and > avoid pointers entirely. We're already doing that in > `CStr::from_bytes_with_nul_unchecked`". `CStr::from_bytes_with_nul_unchecked` does the transmute with references. That is a usage that the docs of `transmute` explicitly recommend to change to an `as` cast [1]. No idea about provenance still. [1]: https://doc.rust-lang.org/std/mem/fn.transmute.html#alternatives >> I tried to find some existing issues about the topic and found that >> there exists a clippy lint `transmute_ptr_to_ptr`. There is an issue >> asking for a better justification [1] and it seems like nobody provided >> one there. Maybe we should ask the opsem team what happens to provenance >> when transmuting? > > Yeah, we should do this - but again: not relevant in this discussion. I think it's pretty relevant. --- Cheers, Benno
On Wed, Mar 26, 2025 at 1:36 PM Benno Lossin <benno.lossin@proton.me> wrote: > > On Wed Mar 26, 2025 at 5:57 PM CET, Tamir Duberstein wrote: > > > > > > In the current code you're looking at, yes. But in the code I have > > locally I'm transmuting `[u8]` to `BStr`. See my earlier reply where I > > said "Hmm, looking at this again we can just transmute ref-to-ref and > > avoid pointers entirely. We're already doing that in > > `CStr::from_bytes_with_nul_unchecked`". > > `CStr::from_bytes_with_nul_unchecked` does the transmute with > references. That is a usage that the docs of `transmute` explicitly > recommend to change to an `as` cast [1]. RIght. That guidance was written in 2016 (https://github.com/rust-lang/rust/pull/34609) and doesn't present any rationale for `as` casts being preferred to transmute. I posted a comment in the most relevant issue I could find: https://github.com/rust-lang/rust/issues/34249#issuecomment-2755316610. > No idea about provenance still. Well that's not surprising, nobody was thinking about provenance in 2016. But I really don't think we should blindly follow the advice in this case. It doesn't make an iota of sense to me - does it make sense to you? > > [1]: https://doc.rust-lang.org/std/mem/fn.transmute.html#alternatives > > >> I tried to find some existing issues about the topic and found that > >> there exists a clippy lint `transmute_ptr_to_ptr`. There is an issue > >> asking for a better justification [1] and it seems like nobody provided > >> one there. Maybe we should ask the opsem team what happens to provenance > >> when transmuting? > > > > Yeah, we should do this - but again: not relevant in this discussion. > > I think it's pretty relevant. It's not relevant because we're no longer talking about transmuting pointer to pointer. The two options are: 1. transmute reference to reference. 2. coerce reference to pointer, `as` cast pointer to pointer (triggers `ptr_as_ptr`), reborrow pointer to reference. If anyone can help me understand why (2) is better than (1), I'd certainly appreciate it.
On Wed, Mar 26, 2025 at 3:06 PM Tamir Duberstein <tamird@gmail.com> wrote: > > On Wed, Mar 26, 2025 at 1:36 PM Benno Lossin <benno.lossin@proton.me> wrote: > > > > On Wed Mar 26, 2025 at 5:57 PM CET, Tamir Duberstein wrote: > > > > > > > > > In the current code you're looking at, yes. But in the code I have > > > locally I'm transmuting `[u8]` to `BStr`. See my earlier reply where I > > > said "Hmm, looking at this again we can just transmute ref-to-ref and > > > avoid pointers entirely. We're already doing that in > > > `CStr::from_bytes_with_nul_unchecked`". > > > > `CStr::from_bytes_with_nul_unchecked` does the transmute with > > references. That is a usage that the docs of `transmute` explicitly > > recommend to change to an `as` cast [1]. > > RIght. That guidance was written in 2016 > (https://github.com/rust-lang/rust/pull/34609) and doesn't present any > rationale for `as` casts being preferred to transmute. I posted a > comment in the most relevant issue I could find: > https://github.com/rust-lang/rust/issues/34249#issuecomment-2755316610. > > > No idea about provenance still. > > Well that's not surprising, nobody was thinking about provenance in > 2016. But I really don't think we should blindly follow the advice in > this case. It doesn't make an iota of sense to me - does it make sense > to you? > > > > > [1]: https://doc.rust-lang.org/std/mem/fn.transmute.html#alternatives > > > > >> I tried to find some existing issues about the topic and found that > > >> there exists a clippy lint `transmute_ptr_to_ptr`. There is an issue > > >> asking for a better justification [1] and it seems like nobody provided > > >> one there. Maybe we should ask the opsem team what happens to provenance > > >> when transmuting? > > > > > > Yeah, we should do this - but again: not relevant in this discussion. > > > > I think it's pretty relevant. > > It's not relevant because we're no longer talking about transmuting > pointer to pointer. The two options are: > 1. transmute reference to reference. > 2. coerce reference to pointer, `as` cast pointer to pointer (triggers > `ptr_as_ptr`), reborrow pointer to reference. > > If anyone can help me understand why (2) is better than (1), I'd > certainly appreciate it. Turns out there's a tortured past even in the standard library. In 2017 someone replaces trasmutes with pointer casts: https://github.com/rust-lang/rust/commit/2633b85ab2c89822d2c227fc9e81c6ec1c0ed9b6 In 2020 someone changes it back to transmute: https://github.com/rust-lang/rust/pull/75157/files See also https://github.com/rust-lang/rust/pull/34609#issuecomment-230559871 which makes my point better than I have, particularly this snippet: "In addition, casting through raw pointers removes the check that both types have the same size that transmute does provide.".
On Wed Mar 26, 2025 at 8:06 PM CET, Tamir Duberstein wrote: > On Wed, Mar 26, 2025 at 1:36 PM Benno Lossin <benno.lossin@proton.me> wrote: >> On Wed Mar 26, 2025 at 5:57 PM CET, Tamir Duberstein wrote: >> > In the current code you're looking at, yes. But in the code I have >> > locally I'm transmuting `[u8]` to `BStr`. See my earlier reply where I >> > said "Hmm, looking at this again we can just transmute ref-to-ref and >> > avoid pointers entirely. We're already doing that in >> > `CStr::from_bytes_with_nul_unchecked`". >> >> `CStr::from_bytes_with_nul_unchecked` does the transmute with >> references. That is a usage that the docs of `transmute` explicitly >> recommend to change to an `as` cast [1]. > > RIght. That guidance was written in 2016 > (https://github.com/rust-lang/rust/pull/34609) and doesn't present any > rationale for `as` casts being preferred to transmute. I posted a > comment in the most relevant issue I could find: > https://github.com/rust-lang/rust/issues/34249#issuecomment-2755316610. Not sure if that's the correct issue, maybe we should post one on the UCG (unsafe code guidelines). But before that we probably should ask on zulip... >> No idea about provenance still. > > Well that's not surprising, nobody was thinking about provenance in > 2016. But I really don't think we should blindly follow the advice in > this case. It doesn't make an iota of sense to me - does it make sense > to you? For ptr-to-int transmutes, I know that they will probably remove provenance, hence I am a bit cautious about using them for ptr-to-ptr or ref-to-ref. >> [1]: https://doc.rust-lang.org/std/mem/fn.transmute.html#alternatives >> >> >> I tried to find some existing issues about the topic and found that >> >> there exists a clippy lint `transmute_ptr_to_ptr`. There is an issue >> >> asking for a better justification [1] and it seems like nobody provided >> >> one there. Maybe we should ask the opsem team what happens to provenance >> >> when transmuting? >> > >> > Yeah, we should do this - but again: not relevant in this discussion. >> >> I think it's pretty relevant. > > It's not relevant because we're no longer talking about transmuting > pointer to pointer. The two options are: > 1. transmute reference to reference. > 2. coerce reference to pointer, `as` cast pointer to pointer (triggers > `ptr_as_ptr`), reborrow pointer to reference. > > If anyone can help me understand why (2) is better than (1), I'd > certainly appreciate it. I am very confident that (2) is correct. With (1) I'm not sure (see above), so that's why I mentioned it. --- Cheers, Benno
On Wed, Mar 26, 2025 at 5:09 PM Benno Lossin <benno.lossin@proton.me> wrote: > > On Wed Mar 26, 2025 at 8:06 PM CET, Tamir Duberstein wrote: > > On Wed, Mar 26, 2025 at 1:36 PM Benno Lossin <benno.lossin@proton.me> wrote: > >> On Wed Mar 26, 2025 at 5:57 PM CET, Tamir Duberstein wrote: > >> > In the current code you're looking at, yes. But in the code I have > >> > locally I'm transmuting `[u8]` to `BStr`. See my earlier reply where I > >> > said "Hmm, looking at this again we can just transmute ref-to-ref and > >> > avoid pointers entirely. We're already doing that in > >> > `CStr::from_bytes_with_nul_unchecked`". > >> > >> `CStr::from_bytes_with_nul_unchecked` does the transmute with > >> references. That is a usage that the docs of `transmute` explicitly > >> recommend to change to an `as` cast [1]. > > > > RIght. That guidance was written in 2016 > > (https://github.com/rust-lang/rust/pull/34609) and doesn't present any > > rationale for `as` casts being preferred to transmute. I posted a > > comment in the most relevant issue I could find: > > https://github.com/rust-lang/rust/issues/34249#issuecomment-2755316610. > > Not sure if that's the correct issue, maybe we should post one on the > UCG (unsafe code guidelines). But before that we probably should ask on > zulip... > > >> No idea about provenance still. > > > > Well that's not surprising, nobody was thinking about provenance in > > 2016. But I really don't think we should blindly follow the advice in > > this case. It doesn't make an iota of sense to me - does it make sense > > to you? > > For ptr-to-int transmutes, I know that they will probably remove > provenance, hence I am a bit cautious about using them for ptr-to-ptr or > ref-to-ref. > > >> [1]: https://doc.rust-lang.org/std/mem/fn.transmute.html#alternatives > >> > >> >> I tried to find some existing issues about the topic and found that > >> >> there exists a clippy lint `transmute_ptr_to_ptr`. There is an issue > >> >> asking for a better justification [1] and it seems like nobody provided > >> >> one there. Maybe we should ask the opsem team what happens to provenance > >> >> when transmuting? > >> > > >> > Yeah, we should do this - but again: not relevant in this discussion. > >> > >> I think it's pretty relevant. > > > > It's not relevant because we're no longer talking about transmuting > > pointer to pointer. The two options are: > > 1. transmute reference to reference. > > 2. coerce reference to pointer, `as` cast pointer to pointer (triggers > > `ptr_as_ptr`), reborrow pointer to reference. > > > > If anyone can help me understand why (2) is better than (1), I'd > > certainly appreciate it. > > I am very confident that (2) is correct. With (1) I'm not sure (see > above), so that's why I mentioned it. Can you help me understand why you're confident about (2) but not (1)?
On Wed Mar 26, 2025 at 11:09 PM CET, Tamir Duberstein wrote: > On Wed, Mar 26, 2025 at 5:09 PM Benno Lossin <benno.lossin@proton.me> wrote: >> On Wed Mar 26, 2025 at 8:06 PM CET, Tamir Duberstein wrote: >> > On Wed, Mar 26, 2025 at 1:36 PM Benno Lossin <benno.lossin@proton.me> wrote: >> >> On Wed Mar 26, 2025 at 5:57 PM CET, Tamir Duberstein wrote: >> >> > >> >> > Yeah, we should do this - but again: not relevant in this discussion. >> >> >> >> I think it's pretty relevant. >> > >> > It's not relevant because we're no longer talking about transmuting >> > pointer to pointer. The two options are: >> > 1. transmute reference to reference. >> > 2. coerce reference to pointer, `as` cast pointer to pointer (triggers >> > `ptr_as_ptr`), reborrow pointer to reference. >> > >> > If anyone can help me understand why (2) is better than (1), I'd >> > certainly appreciate it. >> >> I am very confident that (2) is correct. With (1) I'm not sure (see >> above), so that's why I mentioned it. > > Can you help me understand why you're confident about (2) but not (1)? My explanation from above explains why I'm not confident about (1): For ptr-to-int transmutes, I know that they will probably remove provenance, hence I am a bit cautious about using them for ptr-to-ptr or ref-to-ref. The reason I'm confident about (2) is that that is the canonical way to cast the type of a reference pointing to an `!Sized` value. --- Cheers, Benno
On Wed, Mar 26, 2025 at 6:15 PM Benno Lossin <benno.lossin@proton.me> wrote: > > On Wed Mar 26, 2025 at 11:09 PM CET, Tamir Duberstein wrote: > > On Wed, Mar 26, 2025 at 5:09 PM Benno Lossin <benno.lossin@proton.me> wrote: > >> On Wed Mar 26, 2025 at 8:06 PM CET, Tamir Duberstein wrote: > >> > On Wed, Mar 26, 2025 at 1:36 PM Benno Lossin <benno.lossin@proton.me> wrote: > >> >> On Wed Mar 26, 2025 at 5:57 PM CET, Tamir Duberstein wrote: > >> >> > > >> >> > Yeah, we should do this - but again: not relevant in this discussion. > >> >> > >> >> I think it's pretty relevant. > >> > > >> > It's not relevant because we're no longer talking about transmuting > >> > pointer to pointer. The two options are: > >> > 1. transmute reference to reference. > >> > 2. coerce reference to pointer, `as` cast pointer to pointer (triggers > >> > `ptr_as_ptr`), reborrow pointer to reference. > >> > > >> > If anyone can help me understand why (2) is better than (1), I'd > >> > certainly appreciate it. > >> > >> I am very confident that (2) is correct. With (1) I'm not sure (see > >> above), so that's why I mentioned it. > > > > Can you help me understand why you're confident about (2) but not (1)? > > My explanation from above explains why I'm not confident about (1): > > For ptr-to-int transmutes, I know that they will probably remove > provenance, hence I am a bit cautious about using them for ptr-to-ptr or > ref-to-ref. > > The reason I'm confident about (2) is that that is the canonical way to > cast the type of a reference pointing to an `!Sized` value. Do you have a citation, other than the transmute doc?
On Thu, Mar 27, 2025 at 10:15 AM Tamir Duberstein <tamird@gmail.com> wrote: > > On Wed, Mar 26, 2025 at 6:15 PM Benno Lossin <benno.lossin@proton.me> wrote: > > > > On Wed Mar 26, 2025 at 11:09 PM CET, Tamir Duberstein wrote: > > > On Wed, Mar 26, 2025 at 5:09 PM Benno Lossin <benno.lossin@proton.me> wrote: > > >> On Wed Mar 26, 2025 at 8:06 PM CET, Tamir Duberstein wrote: > > >> > On Wed, Mar 26, 2025 at 1:36 PM Benno Lossin <benno.lossin@proton.me> wrote: > > >> >> On Wed Mar 26, 2025 at 5:57 PM CET, Tamir Duberstein wrote: > > >> >> > > > >> >> > Yeah, we should do this - but again: not relevant in this discussion. > > >> >> > > >> >> I think it's pretty relevant. > > >> > > > >> > It's not relevant because we're no longer talking about transmuting > > >> > pointer to pointer. The two options are: > > >> > 1. transmute reference to reference. > > >> > 2. coerce reference to pointer, `as` cast pointer to pointer (triggers > > >> > `ptr_as_ptr`), reborrow pointer to reference. > > >> > > > >> > If anyone can help me understand why (2) is better than (1), I'd > > >> > certainly appreciate it. > > >> > > >> I am very confident that (2) is correct. With (1) I'm not sure (see > > >> above), so that's why I mentioned it. > > > > > > Can you help me understand why you're confident about (2) but not (1)? > > > > My explanation from above explains why I'm not confident about (1): > > > > For ptr-to-int transmutes, I know that they will probably remove > > provenance, hence I am a bit cautious about using them for ptr-to-ptr or > > ref-to-ref. > > > > The reason I'm confident about (2) is that that is the canonical way to > > cast the type of a reference pointing to an `!Sized` value. > > Do you have a citation, other than the transmute doc? Turns out this appeases clippy: diff --git a/rust/kernel/uaccess.rs b/rust/kernel/uaccess.rs index 80a9782b1c6e..7a6fc78fc314 100644 --- a/rust/kernel/uaccess.rs +++ b/rust/kernel/uaccess.rs @@ -240,9 +240,10 @@ pub fn read_raw(&mut self, out: &mut [MaybeUninit<u8>]) -> Result { /// Fails with [`EFAULT`] if the read happens on a bad address, or if the read goes out of /// bounds of this [`UserSliceReader`]. This call may modify `out` even if it returns an error. pub fn read_slice(&mut self, out: &mut [u8]) -> Result { + let out: *mut [u8] = out; // SAFETY: The types are compatible and `read_raw` doesn't write uninitialized bytes to // `out`. - let out = unsafe { &mut *(out as *mut [u8] as *mut [MaybeUninit<u8>]) }; + let out = unsafe { &mut *(out as *mut [MaybeUninit<u8>]) }; self.read_raw(out) } Benno, would that work for you? Same in str.rs, of course.
On Thu Mar 27, 2025 at 8:44 PM CET, Tamir Duberstein wrote: > On Thu, Mar 27, 2025 at 10:15 AM Tamir Duberstein <tamird@gmail.com> wrote: >> On Wed, Mar 26, 2025 at 6:15 PM Benno Lossin <benno.lossin@proton.me> wrote: >> > On Wed Mar 26, 2025 at 11:09 PM CET, Tamir Duberstein wrote: >> > > On Wed, Mar 26, 2025 at 5:09 PM Benno Lossin <benno.lossin@proton.me> wrote: >> > >> On Wed Mar 26, 2025 at 8:06 PM CET, Tamir Duberstein wrote: >> > >> > On Wed, Mar 26, 2025 at 1:36 PM Benno Lossin <benno.lossin@proton.me> wrote: >> > >> >> On Wed Mar 26, 2025 at 5:57 PM CET, Tamir Duberstein wrote: >> > >> >> > >> > >> >> > Yeah, we should do this - but again: not relevant in this discussion. >> > >> >> >> > >> >> I think it's pretty relevant. >> > >> > >> > >> > It's not relevant because we're no longer talking about transmuting >> > >> > pointer to pointer. The two options are: >> > >> > 1. transmute reference to reference. >> > >> > 2. coerce reference to pointer, `as` cast pointer to pointer (triggers >> > >> > `ptr_as_ptr`), reborrow pointer to reference. >> > >> > >> > >> > If anyone can help me understand why (2) is better than (1), I'd >> > >> > certainly appreciate it. >> > >> >> > >> I am very confident that (2) is correct. With (1) I'm not sure (see >> > >> above), so that's why I mentioned it. >> > > >> > > Can you help me understand why you're confident about (2) but not (1)? >> > >> > My explanation from above explains why I'm not confident about (1): >> > >> > For ptr-to-int transmutes, I know that they will probably remove >> > provenance, hence I am a bit cautious about using them for ptr-to-ptr or >> > ref-to-ref. >> > >> > The reason I'm confident about (2) is that that is the canonical way to >> > cast the type of a reference pointing to an `!Sized` value. >> >> Do you have a citation, other than the transmute doc? Not that I am aware of anything. > Turns out this appeases clippy: > > diff --git a/rust/kernel/uaccess.rs b/rust/kernel/uaccess.rs > index 80a9782b1c6e..7a6fc78fc314 100644 > --- a/rust/kernel/uaccess.rs > +++ b/rust/kernel/uaccess.rs > @@ -240,9 +240,10 @@ pub fn read_raw(&mut self, out: &mut > [MaybeUninit<u8>]) -> Result { > /// Fails with [`EFAULT`] if the read happens on a bad address, > or if the read goes out of > /// bounds of this [`UserSliceReader`]. This call may modify > `out` even if it returns an error. > pub fn read_slice(&mut self, out: &mut [u8]) -> Result { > + let out: *mut [u8] = out; > // SAFETY: The types are compatible and `read_raw` doesn't > write uninitialized bytes to > // `out`. > - let out = unsafe { &mut *(out as *mut [u8] as *mut > [MaybeUninit<u8>]) }; > + let out = unsafe { &mut *(out as *mut [MaybeUninit<u8>]) }; > self.read_raw(out) > } Seems like your email client auto-wrapped that :( > Benno, would that work for you? Same in str.rs, of course. For this specific case, I do have a `cast_slice_mut` function I mentioned in the other thread, but that is still stuck in the untrusted data series, I hope that it's ready tomorrow or maybe next week. I'd prefer if we use that (since its implementation also doesn't use `as` casts :). But if you can't wait, then the above is fine. --- Cheers, Benno
This started with a patch that enabled `clippy::ptr_as_ptr`. Benno Lossin suggested I also look into `clippy::ptr_cast_constness` and I discovered `clippy::as_ptr_cast_mut`. This series now enables all 3 lints. It also enables `clippy::as_underscore` which ensures other pointer casts weren't missed. The first commit reduces the need for pointer casts and is shared with another series[1]. As a later addition, `clippy::cast_lossless` and `clippy::ref_as_ptr` are also enabled. Link: https://lore.kernel.org/all/20250307-no-offset-v1-0-0c728f63b69c@gmail.com/ [1] Signed-off-by: Tamir Duberstein <tamird@gmail.com> --- Changes in v7: - Add patch to enable `clippy::ref_as_ptr`. - Link to v6: https://lore.kernel.org/r/20250324-ptr-as-ptr-v6-0-49d1b7fd4290@gmail.com Changes in v6: - Drop strict provenance patch. - Fix URLs in doc comments. - Add patch to enable `clippy::cast_lossless`. - Rebase on rust-next. - Link to v5: https://lore.kernel.org/r/20250317-ptr-as-ptr-v5-0-5b5f21fa230a@gmail.com Changes in v5: - Use `pointer::addr` in OF. (Boqun Feng) - Add documentation on stubs. (Benno Lossin) - Mark stubs `#[inline]`. - Pick up Alice's RB on a shared commit from https://lore.kernel.org/all/Z9f-3Aj3_FWBZRrm@google.com/. - Link to v4: https://lore.kernel.org/r/20250315-ptr-as-ptr-v4-0-b2d72c14dc26@gmail.com Changes in v4: - Add missing SoB. (Benno Lossin) - Use `without_provenance_mut` in alloc. (Boqun Feng) - Limit strict provenance lints to the `kernel` crate to avoid complex logic in the build system. This can be revisited on MSRV >= 1.84.0. - Rebase on rust-next. - Link to v3: https://lore.kernel.org/r/20250314-ptr-as-ptr-v3-0-e7ba61048f4a@gmail.com Changes in v3: - Fixed clippy warning in rust/kernel/firmware.rs. (kernel test robot) Link: https://lore.kernel.org/all/202503120332.YTCpFEvv-lkp@intel.com/ - s/as u64/as bindings::phys_addr_t/g. (Benno Lossin) - Use strict provenance APIs and enable lints. (Benno Lossin) - Link to v2: https://lore.kernel.org/r/20250309-ptr-as-ptr-v2-0-25d60ad922b7@gmail.com Changes in v2: - Fixed typo in first commit message. - Added additional patches, converted to series. - Link to v1: https://lore.kernel.org/r/20250307-ptr-as-ptr-v1-1-582d06514c98@gmail.com --- Tamir Duberstein (7): rust: retain pointer mut-ness in `container_of!` rust: enable `clippy::ptr_as_ptr` lint rust: enable `clippy::ptr_cast_constness` lint rust: enable `clippy::as_ptr_cast_mut` lint rust: enable `clippy::as_underscore` lint rust: enable `clippy::cast_lossless` lint rust: enable `clippy::ref_as_ptr` lint Makefile | 6 ++++++ drivers/gpu/drm/drm_panic_qr.rs | 10 +++++----- rust/bindings/lib.rs | 3 +++ rust/kernel/alloc/allocator_test.rs | 2 +- rust/kernel/alloc/kvec.rs | 4 ++-- rust/kernel/block/mq/operations.rs | 2 +- rust/kernel/block/mq/request.rs | 7 ++++--- rust/kernel/device.rs | 5 +++-- rust/kernel/device_id.rs | 5 +++-- rust/kernel/devres.rs | 19 ++++++++++--------- rust/kernel/dma.rs | 6 +++--- rust/kernel/error.rs | 2 +- rust/kernel/firmware.rs | 3 ++- rust/kernel/fs/file.rs | 3 ++- rust/kernel/io.rs | 18 +++++++++--------- rust/kernel/kunit.rs | 15 +++++++-------- rust/kernel/lib.rs | 5 ++--- rust/kernel/list/impl_list_item_mod.rs | 2 +- rust/kernel/miscdevice.rs | 2 +- rust/kernel/net/phy.rs | 4 ++-- rust/kernel/of.rs | 6 +++--- rust/kernel/pci.rs | 13 ++++++++----- rust/kernel/platform.rs | 6 ++++-- rust/kernel/print.rs | 11 +++++------ rust/kernel/rbtree.rs | 23 ++++++++++------------- rust/kernel/seq_file.rs | 3 ++- rust/kernel/str.rs | 14 +++++++------- rust/kernel/sync/poll.rs | 2 +- rust/kernel/uaccess.rs | 5 +++-- rust/kernel/workqueue.rs | 12 ++++++------ rust/uapi/lib.rs | 3 +++ 31 files changed, 120 insertions(+), 101 deletions(-) --- base-commit: 28bb48c4cb34f65a9aa602142e76e1426da31293 change-id: 20250307-ptr-as-ptr-21b1867fc4d4 Best regards,