[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <75146bf9-7bd3-d638-5c6b-23c7327a6f49@gmail.com>
Date: Fri, 14 Jul 2023 12:10:19 -0300
From: Martin Rodriguez Reboredo <yakoyoku@...il.com>
To: Asahi Lina <lina@...hilina.net>, Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>,
Wedson Almeida Filho <wedsonaf@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>,
Masahiro Yamada <masahiroy@...nel.org>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Nicolas Schier <nicolas@...sle.eu>, Tom Rix <trix@...hat.com>,
Daniel Vetter <daniel@...ll.ch>
Cc: Hector Martin <marcan@...can.st>, Sven Peter <sven@...npeter.dev>,
Alyssa Rosenzweig <alyssa@...enzweig.io>,
asahi@...ts.linux.dev, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org,
llvm@...ts.linux.dev
Subject: Re: [PATCH RFC 06/11] rust: sync: Replace static LockClassKey refs
with a pointer wrapper
On 7/14/23 06:13, Asahi Lina wrote:
> We want to be able to handle dynamic lock class creation and using
> pointers to things that aren't a real lock_class_key as lock classes.
> Doing this by casting around Rust references is difficult without
> accidentally invoking UB.
>
> Instead, switch LockClassKey to being a raw pointer wrapper around a
> lock_class_key, which means there is no UB possible on the Rust side
> just by creating and consuming these objects. The C code also should
> never actually dereference lock classes, only use their address
> (possibly with an offset).
>
> We still provide a dummy ZST version of this wrapper, to be used when
> lockdep is disabled.
>
> Signed-off-by: Asahi Lina <lina@...hilina.net>
> ---
> [...]
> diff --git a/rust/kernel/sync/lockdep.rs b/rust/kernel/sync/lockdep.rs
> index cb68b18dc0ad..d8328f4275fb 100644
> --- a/rust/kernel/sync/lockdep.rs
> +++ b/rust/kernel/sync/lockdep.rs
> @@ -9,19 +9,36 @@
>
> /// Represents a lockdep class. It's a wrapper around C's `lock_class_key`.
> #[repr(transparent)]
> -pub struct LockClassKey(Opaque<bindings::lock_class_key>);
> +pub struct StaticLockClassKey(Opaque<bindings::lock_class_key>);
>
> -impl LockClassKey {
> +impl StaticLockClassKey {
> /// Creates a new lock class key.
> pub const fn new() -> Self {
> Self(Opaque::uninit())
> }
>
> + /// Returns the lock class key reference for this static lock class.
> + pub const fn key(&self) -> LockClassKey {
> + LockClassKey(self.0.get())
`Opaque::get` is not a `const fn` so this will not compile.
> + }
> +}
> +
> +// SAFETY: `bindings::lock_class_key` just represents an opaque memory location, and is never
> +// actually dereferenced.
> +unsafe impl Sync for StaticLockClassKey {}
> +
> +/// A reference to a lock class key. This is a raw pointer to a lock_class_key,
> +/// which is required to have a static lifetime.
> +#[derive(Copy, Clone)]
> +pub struct LockClassKey(*mut bindings::lock_class_key);
> +
> +impl LockClassKey {
> pub(crate) fn as_ptr(&self) -> *mut bindings::lock_class_key {
I think this can be made into a `const fn`. What do you all think?
> - self.0.get()
> + self.0
> }
> }
>
> [...]
Powered by blists - more mailing lists