From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch [79.135.106.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 98D862080F4; Wed, 26 Mar 2025 17:36:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=79.135.106.29 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743010571; cv=none; b=IWlxH7vBbbL+p9rUDOdB4dR/AN6Ri7YfyM79dAUgheGryOecmLvR8tIuafLLU89ETP2d9Y6uJv/RRppSju58rZ2qk0e7MOPqJvrDfTAwu7jquXs/00va5yl8Aq3cn52KSEoOCXfsuNkeUEFacX6bz/SnV5QYy5IKz7tMtqMvwM8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1743010571; c=relaxed/simple; bh=vmo70qi4jubeax8r03jesK1Pt//JC5tXOdcGJJd8Swc=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=GpcGoO35bx5qFUQ/H1koMela2L9RaAqCHWI3rDN6iZa7+tcNU1BEkFgG/RmXMlP+IpXnnArzRI+J4ykmcwsiVfJURa9Nnuq5KpMMs6cKEVglgH2YdvOYzh1WPbmh0vKG6/B5zQ+eG502FnzUkWVq6CVHaai07gLHPZcGigN9Afk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me; spf=pass smtp.mailfrom=proton.me; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b=KLeAnQw7; arc=none smtp.client-ip=79.135.106.29 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=proton.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b="KLeAnQw7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1743010566; x=1743269766; bh=ISTNGVgFNAIYx4YxVawxUgwnjBdmAFD9xRz8nBxjPR4=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=KLeAnQw7pMwTIc0aP8iawFI8ULRG+OGlYN/wCnE45deKP4azWBgmStXT+icgK/+NK wv4nibfgtrEPn2ayPX1GCkqf/OcZ4xvleZX0dAm++M/xykGsV/A2eI5gFpsR+5p1ki uM4mSYToshLeMtIIXgxDyQvbB+R3/n2EpSPb6Aipx4oB7Ng10QGx/nRd50g76irVxH VFEJoigZu8OkUii3xC7p3pXKV/7QSBllcv8VGqOkzqLWdvI5gvuakA0M+osHV3k5R5 ylVKJaUq+efycUbXXYSbzu5Zz9ssEVULj0ZPmQloCwKSrrONqFy77iu8W7tgUEDjRI 22E/xuo2GEh3g== Date: Wed, 26 Mar 2025 17:36:01 +0000 To: Tamir Duberstein From: Benno Lossin Cc: Masahiro Yamada , Nathan Chancellor , Nicolas Schier , Miguel Ojeda , Alex Gaynor , Boqun Feng , Gary Guo , =?utf-8?Q?Bj=C3=B6rn_Roy_Baron?= , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich , Greg Kroah-Hartman , "Rafael J. Wysocki" , Brendan Higgins , David Gow , Rae Moar , Bjorn Helgaas , Luis Chamberlain , Russ Weight , Rob Herring , Saravana Kannan , Abdiel Janulgue , Daniel Almeida , Robin Murphy , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , FUJITA Tomonori , linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-kselftest@vger.kernel.org, kunit-dev@googlegroups.com, linux-pci@vger.kernel.org, linux-block@vger.kernel.org, devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org, netdev@vger.kernel.org Subject: Re: [PATCH v7 7/7] rust: enable `clippy::ref_as_ptr` lint Message-ID: In-Reply-To: References: <20250325-ptr-as-ptr-v7-0-87ab452147b9@gmail.com> <20250325-ptr-as-ptr-v7-7-87ab452147b9@gmail.com> Feedback-ID: 71780778:user:proton X-Pm-Message-ID: c0a294e4fdda451a84b260cbeb67b2c355063bc8 Precedence: bulk X-Mailing-List: linux-pci@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed Mar 26, 2025 at 5:57 PM CET, Tamir Duberstein wrote: > On Wed, Mar 26, 2025 at 12:43=E2=80=AFPM Benno Lossin wrote: >> On Wed Mar 26, 2025 at 11:35 AM CET, Tamir Duberstein wrote: >> > On Wed, Mar 26, 2025 at 6:31=E2=80=AFAM Benno Lossin wrote: >> >> On Wed Mar 26, 2025 at 12:54 AM CET, Tamir Duberstein wrote: >> >> > On Tue, Mar 25, 2025 at 6:40=E2=80=AFPM Benno Lossin wrote: >> >> >> On Tue Mar 25, 2025 at 11:33 PM CET, Tamir Duberstein wrote: >> >> >> > On Tue, Mar 25, 2025 at 6:11=E2=80=AFPM Benno Lossin 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], *con= st Self>(bytes)) } >> >> >> >> >> >> >> >> Hmm I'm not sure about using `transmute` here. Yes the types ar= e >> >> >> >> transparent, but I don't think that we should use it here. >> >> >> > >> >> >> > What's your suggestion? I initially tried >> >> >> > >> >> >> > let bytes: *const [u8] =3D 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 th= e `as` >> >> >> cast. So: >> >> >> >> >> >> let bytes: *const [u8] =3D bytes; >> >> >> // CAST: `BStr` transparently wraps `[u8]`. >> >> >> let bytes =3D 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 avo= id >> >> > 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 thi= nk >> >> 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