| Message ID | 20250325-ptr-as-ptr-v7-7-87ab452147b9@gmail.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | rust: reduce `as` casts, enable related lints | expand |
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. > } > > /// 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. --- Cheers, Benno > self.read_raw(out) > } >
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 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
diff --git a/Makefile b/Makefile index 2e9eca8b7671..081b5fa2aa81 100644 --- a/Makefile +++ b/Makefile @@ -488,6 +488,7 @@ export rust_common_flags := --edition=2021 \ -Wclippy::no_mangle_with_rust_abi \ -Wclippy::ptr_as_ptr \ -Wclippy::ptr_cast_constness \ + -Wclippy::ref_as_ptr \ -Wclippy::undocumented_unsafe_blocks \ -Wclippy::unnecessary_safety_comment \ -Wclippy::unnecessary_safety_doc \ diff --git a/rust/bindings/lib.rs b/rust/bindings/lib.rs index b105a0d899cc..2b69016070c6 100644 --- a/rust/bindings/lib.rs +++ b/rust/bindings/lib.rs @@ -27,6 +27,7 @@ #[allow(dead_code)] #[allow(clippy::cast_lossless)] #[allow(clippy::ptr_as_ptr)] +#[allow(clippy::ref_as_ptr)] #[allow(clippy::undocumented_unsafe_blocks)] mod bindings_raw { // Manual definition for blocklisted types. diff --git a/rust/kernel/device_id.rs b/rust/kernel/device_id.rs index 4063f09d76d9..37cc03d1df4c 100644 --- a/rust/kernel/device_id.rs +++ b/rust/kernel/device_id.rs @@ -136,7 +136,8 @@ impl<T: RawDeviceId, U, const N: usize> IdTable<T, U> for IdArray<T, U, N> { fn as_ptr(&self) -> *const T::RawType { // This cannot be `self.ids.as_ptr()`, as the return pointer must have correct provenance // to access the sentinel. - (self as *const Self).cast() + let this: *const Self = self; + this.cast() } fn id(&self, index: usize) -> &T::RawType { diff --git a/rust/kernel/fs/file.rs b/rust/kernel/fs/file.rs index 9e2639aee61a..366e23dc0803 100644 --- a/rust/kernel/fs/file.rs +++ b/rust/kernel/fs/file.rs @@ -359,12 +359,13 @@ impl core::ops::Deref for File { type Target = LocalFile; #[inline] fn deref(&self) -> &LocalFile { + let this: *const Self = self; // SAFETY: The caller provides a `&File`, and since it is a reference, it must point at a // valid file for the desired duration. // // By the type invariants, there are no `fdget_pos` calls that did not take the // `f_pos_lock` mutex. - unsafe { LocalFile::from_raw_file((self as *const Self).cast()) } + unsafe { LocalFile::from_raw_file(this.cast()) } } } 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)) } } /// 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)) }; self.read_raw(out) } @@ -348,6 +348,7 @@ pub fn write<T: AsBytes>(&mut self, value: &T) -> Result { if len > self.length { return Err(EFAULT); } + let value: *const T = value; // SAFETY: The reference points to a value of type `T`, so it is valid for reading // `size_of::<T>()` bytes. // @@ -357,7 +358,7 @@ pub fn write<T: AsBytes>(&mut self, value: &T) -> Result { let res = unsafe { bindings::_copy_to_user( self.ptr as *mut c_void, - (value as *const T).cast::<c_void>(), + value.cast::<c_void>(), len, ) }; diff --git a/rust/uapi/lib.rs b/rust/uapi/lib.rs index d5dab4dfabec..6230ba48201d 100644 --- a/rust/uapi/lib.rs +++ b/rust/uapi/lib.rs @@ -16,6 +16,7 @@ clippy::all, clippy::cast_lossless, clippy::ptr_as_ptr, + clippy::ref_as_ptr, clippy::undocumented_unsafe_blocks, dead_code, missing_docs,