[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ-ks9nCdcn7ajG69m+2QTgYxvELd2h7kdBb_bLpTwQbnZ8X_Q@mail.gmail.com>
Date: Mon, 17 Mar 2025 14:33:14 -0400
From: Tamir Duberstein <tamird@...il.com>
To: Benno Lossin <benno.lossin@...ton.me>
Cc: Masahiro Yamada <masahiroy@...nel.org>, Nathan Chancellor <nathan@...nel.org>,
Nicolas Schier <nicolas@...sle.eu>, Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>,
Gary Guo <gary@...yguo.net>, Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael J. Wysocki" <rafael@...nel.org>,
Brendan Higgins <brendan.higgins@...ux.dev>, David Gow <davidgow@...gle.com>,
Rae Moar <rmoar@...gle.com>, Bjorn Helgaas <bhelgaas@...gle.com>,
Luis Chamberlain <mcgrof@...nel.org>, Russ Weight <russ.weight@...ux.dev>, Rob Herring <robh@...nel.org>,
Saravana Kannan <saravanak@...gle.com>, linux-kbuild@...r.kernel.org,
linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
linux-kselftest@...r.kernel.org, kunit-dev@...glegroups.com,
linux-pci@...r.kernel.org, linux-block@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH v5 6/6] rust: use strict provenance APIs
On Mon, Mar 17, 2025 at 2:31 PM Tamir Duberstein <tamird@...il.com> wrote:
>
> On Mon, Mar 17, 2025 at 1:50 PM Benno Lossin <benno.lossin@...ton.me> wrote:
> >
> > On Mon Mar 17, 2025 at 3:23 PM CET, Tamir Duberstein wrote:
> > > Throughout the tree, use the strict provenance APIs stabilized in Rust
> > > 1.84.0[1]. Retain backwards-compatibility by introducing forwarding
> > > functions at the `kernel` crate root along with polyfills for rustc <
> > > 1.84.0.
> > >
> > > Use `#[allow(clippy::incompatible_msrv)]` to avoid warnings on rustc <
> > > 1.84.0 as our MSRV is 1.78.0.
> > >
> > > In the `kernel` crate, enable the strict provenance lints on rustc >=
> > > 1.84.0; do this in `lib.rs` rather than `Makefile` to avoid introducing
> > > compiler flags that are dependent on the rustc version in use.
> > >
> > > Link: https://blog.rust-lang.org/2025/01/09/Rust-1.84.0.html#strict-provenance-apis [1]
> > > Suggested-by: Benno Lossin <benno.lossin@...ton.me>
> > > Link: https://lore.kernel.org/all/D8EIXDMRXMJP.36TFCGWZBRS3Y@proton.me/
> > > Signed-off-by: Tamir Duberstein <tamird@...il.com>
> >
> > One comment below, with that fixed:
> >
> > Reviewed-by: Benno Lossin <benno.lossin@...ton.me>
> >
> > > ---
> > > init/Kconfig | 3 ++
> > > rust/kernel/alloc.rs | 2 +-
> > > rust/kernel/devres.rs | 4 +-
> > > rust/kernel/io.rs | 14 +++----
> > > rust/kernel/lib.rs | 108 +++++++++++++++++++++++++++++++++++++++++++++++++
> > > rust/kernel/of.rs | 2 +-
> > > rust/kernel/pci.rs | 4 +-
> > > rust/kernel/str.rs | 16 +++-----
> > > rust/kernel/uaccess.rs | 12 ++++--
> > > 9 files changed, 138 insertions(+), 27 deletions(-)
> >
> >
> > > +#[cfg(not(CONFIG_RUSTC_HAS_STABLE_STRICT_PROVENANCE))]
> > > +mod strict_provenance {
> > > + /// Gets the "address" portion of the pointer.
> > > + ///
> > > + /// See https://doc.rust-lang.org/stable/core/primitive.pointer.html#method.addr.
> > > + #[inline]
> > > + pub fn addr<T>(ptr: *const T) -> usize {
> > > + // This is core's implementation from
> > > + // https://github.com/rust-lang/rust/commit/4291332175d12e79e6061cdc3f5dccac2e28b969 through
> > > + // https://github.com/rust-lang/rust/blob/1.84.0/library/core/src/ptr/const_ptr.rs#L172
> > > + // which is the first version that satisfies `CONFIG_RUSTC_HAS_STABLE_STRICT_PROVENANCE`.
> > > + #[allow(clippy::undocumented_unsafe_blocks)]
> > > + unsafe {
> > > + #[allow(clippy::transmutes_expressible_as_ptr_casts)]
> > > + core::mem::transmute(ptr.cast::<()>())
> > > + }
> >
> > I think we should just use `ptr as usize` here instead. It's going away
> > at some point and it will only affect optimizations (I don't even know
> > if they exist at the moment) of old versions.
>
> Why get cute? I'd rather defer to the standard library.
Ah, this is gone anyway with Boqun's suggestion - this function exists in 1.78.
Powered by blists - more mailing lists