Re: [PATCH v7 7/7] rust: enable `clippy::ref_as_ptr` lint
From: Benno Lossin <hidden>
Date: 2025-03-27 22:17:19
Also in:
dri-devel, linux-block, linux-devicetree, linux-kbuild, linux-kselftest, linux-pci, lkml, rust-for-linux
On Thu Mar 27, 2025 at 8:44 PM CET, Tamir Duberstein wrote:
On Thu, Mar 27, 2025 at 10:15 AM Tamir Duberstein [off-list ref] wrote:quoted
On Wed, Mar 26, 2025 at 6:15 PM Benno Lossin [off-list ref] wrote:quoted
On Wed Mar 26, 2025 at 11:09 PM CET, Tamir Duberstein wrote:quoted
On Wed, Mar 26, 2025 at 5:09 PM Benno Lossin [off-list ref] wrote:quoted
On Wed Mar 26, 2025 at 8:06 PM CET, Tamir Duberstein wrote:quoted
On Wed, Mar 26, 2025 at 1:36 PM Benno Lossin [off-list ref] wrote:quoted
On Wed Mar 26, 2025 at 5:57 PM CET, Tamir Duberstein wrote:quoted
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.
quoted hunk ↗ jump to hunk
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