From: Benno Lossin <benno.lossin@proton.me>
To: Alice Ryhl <aliceryhl@google.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
"Andreas Hindborg" <a.hindborg@kernel.org>
Subject: Re: [PATCH v4] rust: add global lock support
Date: Thu, 10 Oct 2024 22:13:38 +0000 [thread overview]
Message-ID: <2f3e6cac-1642-489b-b045-32211e296137@proton.me> (raw)
In-Reply-To: <CAH5fLghsozD0qeTygBM0-WDgXRwtGcsc6B3bT1794QMx3=vSTg@mail.gmail.com>
On 10.10.24 12:53, Alice Ryhl wrote:
> On Thu, Oct 10, 2024 at 12:39 PM Benno Lossin <benno.lossin@proton.me> wrote:
>>
>> On 30.09.24 15:11, Alice Ryhl wrote:
>>> diff --git a/rust/kernel/sync/lock/global.rs b/rust/kernel/sync/lock/global.rs
>>> new file mode 100644
>>> index 000000000000..fc02fac864f6
>>> --- /dev/null
>>> +++ b/rust/kernel/sync/lock/global.rs
>>> @@ -0,0 +1,260 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +
>>> +// Copyright (C) 2024 Google LLC.
>>> +
>>> +//! Support for defining statics containing locks.
>>> +
>>> +/// Defines a global lock.
>>> +///
>>> +/// Supports the following options:
>>> +///
>>> +/// * `value` specifies the initial value in the global lock.
>>> +/// * `wrapper` specifies the name of the wrapper struct.
>>> +/// * `guard` specifies the name of the guard type.
>>> +/// * `locked_by` specifies the name of the `LockedBy` type.
>>> +///
>>> +/// # Examples
>>> +///
>>> +/// A global counter.
>>> +///
>>> +/// ```
>>> +/// # mod ex {
>>> +/// # use kernel::prelude::*;
>>> +/// kernel::sync::global_lock! {
>>> +/// // SAFETY: Initialized in module initializer before first use.
>>> +/// static MY_COUNTER: Mutex<u32> = unsafe { uninit };
>>> +/// value: 0;
>>> +/// }
>>> +///
>>> +/// fn increment_counter() -> u32 {
>>> +/// let mut guard = MY_COUNTER.lock();
>>> +/// *guard += 1;
>>> +/// *guard
>>> +/// }
>>> +///
>>> +/// impl kernel::Module for MyModule {
>>> +/// fn init(_module: &'static ThisModule) -> Result<Self> {
>>> +/// // SAFETY: called exactly once
>>> +/// unsafe { MY_COUNTER.init() };
>>> +///
>>> +/// Ok(MyModule {})
>>> +/// }
>>> +/// }
>>> +/// # struct MyModule {}
>>> +/// # }
>>> +/// ```
>>> +///
>>> +/// A global mutex used to protect all instances of a given struct.
>>> +///
>>> +/// ```
>>> +/// # mod ex {
>>> +/// # use kernel::prelude::*;
>>> +/// kernel::sync::global_lock! {
>>> +/// // SAFETY: Initialized in module initializer before first use.
>>> +/// static MY_MUTEX: Mutex<()> = unsafe { uninit };
>>> +/// value: ();
>>> +/// guard: MyGuard;
>>> +/// locked_by: LockedByMyMutex;
>>> +/// }
>>> +///
>>> +/// /// All instances of this struct are protected by `MY_MUTEX`.
>>> +/// struct MyStruct {
>>> +/// my_counter: LockedByMyMutex<u32>,
>>> +/// }
>>> +///
>>> +/// impl MyStruct {
>>> +/// /// Increment the counter in this instance.
>>> +/// ///
>>> +/// /// The caller must hold the `MY_MUTEX` mutex.
>>> +/// fn increment(&self, guard: &mut MyGuard) -> u32 {
>>> +/// let my_counter = self.my_counter.as_mut(guard);
>>> +/// *my_counter += 1;
>>> +/// *my_counter
>>> +/// }
>>> +/// }
>>> +///
>>> +/// impl kernel::Module for MyModule {
>>> +/// fn init(_module: &'static ThisModule) -> Result<Self> {
>>> +/// // SAFETY: called exactly once
>>> +/// unsafe { MY_MUTEX.init() };
>>> +///
>>> +/// Ok(MyModule {})
>>> +/// }
>>> +/// }
>>> +/// # struct MyModule {}
>>> +/// # }
>>> +/// ```
>>
>> The docs here don't mention that you still need to call `.init()`
>> manually (though the examples show it nicely). I don't know if we want
>> macros to have a `# Safety` section.
>>
>>> +#[macro_export]
>>> +macro_rules! global_lock {
>>> + {
>>> + $(#[$meta:meta])* $pub:vis static $name:ident: $kind:ident<$valuety:ty> = unsafe { uninit };
>>> + value: $value:expr;
>>
>> I would find it more natural to use `=` instead of `:` here, since then
>> it would read as a normal statement with the semicolon at the end.
>> Another alternative would be to use `,` instead of `;`, but that doesn't
>> work nicely with the static keyword above (although you could make the
>> user write it in another {}, but that also isn't ideal...).
>>
>> Using `=` instead of `:` makes my editor put the correct amount of
>> indentation there, `:` adds a lot of extra spaces.
>
> That seems sensible.
>
>>> + wrapper: $wrapper:ident;
>>> + $( name: $lname:literal; )?
>>> + $(
>>> + guard: $guard:ident;
>>> + locked_by: $locked_by:ident;
>>> + )?
>>> + } => {
>>> + $crate::macros::paste! {
>>> + type [< __static_lock_ty_ $name >] = $valuety;
>>> + const [< __static_lock_init_ $name >]: [< __static_lock_ty_ $name >] = $value;
>>
>> Why are these two items outside of the `mod` below?
>> Also why do you need to define the type alias? You could just use
>> `$valuety`, right?
>
> Because they might access things that are in scope here, but not in
> scope inside the module.
Right... That's rather annoying...
>> Also,
>>
>> error: type `__static_lock_ty_VALUE` should have an upper camel case name
>> --> rust/kernel/sync/lock/global.rs:100:18
>> |
>> 100 | type [< __static_lock_ty_ $name >] = $valuety;
>> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: convert the identifier to upper camel case: `StaticLockTyValue`
>>
>> The same error affects the `wrapper` type forwarding below.
>>
>>
>>> +
>>> + #[allow(unused_pub)]
>>
>> error: unknown lint: `unused_pub`
>> --> rust/kernel/sync/lock/global.rs:103:21
>> |
>> 103 | #[allow(unused_pub)]
>> | ^^^^^^^^^^ help: did you mean: `unused_mut`
>
> Uhhh. This is the lint for when you mark a function pub but don't
> actually export it from the crate. But now I can't find the lint
> anywhere ... I'm so confused.
Maybe you mean `unreachable_pub`?
>> Though I also get
>>
>> error: methods `init` and `lock` are never used
>> --> rust/kernel/sync/lock/global.rs:128:42
>> |
>> 122 | / impl $wrapper {
>> 123 | | /// Initialize the global lock.
>> 124 | | ///
>> 125 | | /// # Safety
>> ... |
>> 128 | | pub(crate) unsafe fn init(&'static self) {
>> | | ^^^^
>> ... |
>> 142 | | pub(crate) fn lock(&'static self) -> $crate::global_lock_inner!(guard $kind, $valuety $(, $guard)?) {
>> | | ^^^^
>> ... |
>> 146 | | }
>> 147 | | }
>> | |_________________- methods in this implementation
>>
>> But that is governed by the `dead_code` lint.
>
> I guess I have to look into the lints again. I did not get this lint.
I just put a `global_lock!` invocation into `lib.rs` and didn't use any
of the functions. But maybe we want that to error?
>>> + mod [< __static_lock_mod_ $name >] {
>>> + use super::[< __static_lock_ty_ $name >] as Val;
>>> + use super::[< __static_lock_init_ $name >] as INIT;
>>> + type Backend = $crate::global_lock_inner!(backend $kind);
>>> + type GuardTyp = $crate::global_lock_inner!(guard $kind, Val $(, $guard)?);
>>
>> `GuardTyp` is only used once, so you should be able to just inline it.
>> `Backend` is used twice, but I don't know if we need a type alias for
>> it.
>
> They're both used twice. Inlining them makes the lines really long.
Ah I missed the one on try_lock. It's fine to keep them.
>>> + $wrapper {
>>> + // SAFETY: The user of this macro promises to call `init` before calling
>>> + // `lock`.
>>> + inner: unsafe {
>>> + $crate::sync::lock::Lock::global_lock_helper_new(state, INIT)
>>> + }
>>> + }
>>> + }
>>> +
>>> + /// Wrapper type for a global lock.
>>> + pub(crate) struct $wrapper {
>>
>> How can the wrapper struct be `pub(crate)` when the constant might be
>> global `pub`?
>>
>> error: type `__static_lock_wrapper_INIT` is more private than the item `INIT`
>> --> rust/kernel/sync/lock/global.rs:206:14
>> |
>> 206 | };
>> | ^ static `INIT` is reachable at visibility `pub`
>> |
>>
>> The functions should probably just be `pub`.
>
> I used to do that, but got some errors about `pub` being unused. I'll
> look into this again.
Maybe the `unreachable_pub` lint can help?
---
Cheers,
Benno
next prev parent reply other threads:[~2024-10-10 22:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-30 13:11 [PATCH v4] rust: add global lock support Alice Ryhl
2024-10-10 10:39 ` Benno Lossin
2024-10-10 10:53 ` Alice Ryhl
2024-10-10 13:55 ` Boqun Feng
2024-10-10 13:58 ` Alice Ryhl
2024-10-10 14:29 ` Boqun Feng
2024-10-10 16:33 ` Boqun Feng
2024-10-10 22:21 ` Benno Lossin
2024-10-10 23:06 ` Boqun Feng
2024-10-11 7:01 ` Benno Lossin
2024-10-11 22:43 ` Boqun Feng
2024-10-10 22:13 ` Benno Lossin [this message]
2024-10-10 14:01 ` Andreas Hindborg
2024-10-10 22:14 ` Benno Lossin
2024-10-11 14:57 ` Andreas Hindborg
2024-10-10 13:57 ` Andreas Hindborg
2024-10-10 14:01 ` Alice Ryhl
2024-10-10 14:08 ` Andreas Hindborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2f3e6cac-1642-489b-b045-32211e296137@proton.me \
--to=benno.lossin@proton.me \
--cc=a.hindborg@kernel.org \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).