linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Onur <work@onurozkan.dev>
To: "Benno Lossin" <lossin@kernel.org>
Cc: <rust-for-linux@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<peterz@infradead.org>, <mingo@redhat.com>, <will@kernel.org>,
	<boqun.feng@gmail.com>, <longman@redhat.com>, <ojeda@kernel.org>,
	<alex.gaynor@gmail.com>, <gary@garyguo.net>,
	<bjorn3_gh@protonmail.com>, <a.hindborg@kernel.org>,
	<aliceryhl@google.com>, <tmgross@umich.edu>, <dakr@kernel.org>,
	<thatslyude@gmail.com>
Subject: Re: [PATCH V3] implement `ww_mutex` abstraction for the Rust tree
Date: Sat, 21 Jun 2025 13:32:37 +0300	[thread overview]
Message-ID: <20250621133237.5ccdfa3a@nimda.home> (raw)
In-Reply-To: <DAQL7NBDD68Q.1ZS3PUR0AGN0R@kernel.org>

On Thu, 19 Jun 2025 16:42:15 +0200
"Benno Lossin" <lossin@kernel.org> wrote:

> On Thu Jun 19, 2025 at 4:06 PM CEST, Onur Özkan wrote:
> > From: onur-ozkan <work@onurozkan.dev>
> 
> Can you double-check your name in your git config? This doesn't match
> the Signed-off-by below.

That's strange. It should be "Onur Özkan", gitconfig is the correct
one. I will re-check that on V4 patch.

> > <work@onurozkan.dev> ---
> >  rust/helpers/helpers.c            |   1 +
> >  rust/helpers/ww_mutex.c           |  39 +++
> >  rust/kernel/error.rs              |   1 +
> >  rust/kernel/sync/lock.rs          |   1 +
> >  rust/kernel/sync/lock/ww_mutex.rs | 556
> > ++++++++++++++++++++++++++++++ 5 files changed, 598 insertions(+)
> >  create mode 100644 rust/helpers/ww_mutex.c
> >  create mode 100644 rust/kernel/sync/lock/ww_mutex.rs
> 
> Can you split this patch into multiple smaller ones? For example all
> the tests can be done separately as well as the abstractions for
> `ww_class`, `ww_acquire_ctx` and `ww_mutex`.
> 
> Thanks.

I will try to separate them. It's my first big (relatively) patch-based
work. I am still tryin to get used to it :)


> > +/// ```
> > +/// use kernel::c_str;
> > +/// use kernel::define_ww_class;
> > +///
> > +/// define_ww_class!(WOUND_WAIT_GLOBAL_CLASS, wound_wait,
> > c_str!("wound_wait_global_class")); +///
> > define_ww_class!(WAIT_DIE_GLOBAL_CLASS, wait_die,
> > c_str!("wait_die_global_class")); +/// ``` +#[macro_export]
> > +macro_rules! define_ww_class {
> 
> What's the reason for this being a macro?

It's for creating global classes which was suggested in previous
reviews. A similar approach is used on the C side as well with
`DEFINE_WD_CLASS`.

> > +    ($name:ident, wait_die, $class_name:expr) => {
> > +        static $name: $crate::sync::lock::ww_mutex::WwClass = {
> > +            $crate::sync::lock::ww_mutex::WwClass {
> > +                inner:
> > $crate::types::Opaque::new($crate::bindings::ww_class {
> > +                    stamp: $crate::bindings::atomic_long_t {
> > counter: 0 },
> > +                    acquire_name: $class_name.as_char_ptr(),
> > +                    mutex_name: $class_name.as_char_ptr(),
> > +                    is_wait_die: 1,
> > +                    // TODO: Replace with
> > `bindings::lock_class_key::default()` once stabilized for `const`.
> > +                    //
> > +                    // SAFETY: This is always zero-initialized
> > when defined with `DEFINE_WD_CLASS`
> > +                    // globally on C side.
> > +                    //
> > +                    // Ref:
> > https://github.com/torvalds/linux/blob/master/include/linux/ww_mutex.h#L85-L89
> > +                    acquire_key: unsafe { core::mem::zeroed() },
> > +                    // TODO: Replace with
> > `bindings::lock_class_key::default()` once stabilized for `const`.
> > +                    //
> > +                    // SAFETY: This is always zero-initialized
> > when defined with `DEFINE_WD_CLASS`
> > +                    // globally on C side.
> > +                    //
> > +                    // Ref:
> > https://github.com/torvalds/linux/blob/master/include/linux/ww_mutex.h#L85-L89
> > +                    mutex_key: unsafe { core::mem::zeroed() },
> > +                }),
> > +            }
> > +        };
> > +    };
> > +}
> > +
> > +/// Implementation of C side `ww_class`.
> 
> This isn't informative at all. The names already match, so I wouldn't
> have thought otherwise.

I didn't want to duplicate the docs. I will update it (and others) on
V4.

> > +///
> > +/// Represents a group of mutexes that can participate in deadlock
> > avoidance together. +/// All mutexes that might be acquired
> > together should use the same class. +///
> > +/// # Examples
> > +///
> > +/// ```
> > +/// use kernel::sync::lock::ww_mutex::WwClass;
> > +/// use kernel::c_str;
> > +/// use pin_init::stack_pin_init;
> > +///
> > +/// stack_pin_init!(let _wait_die_class =
> > WwClass::new_wait_die(c_str!("graphics_buffers"))); +///
> > stack_pin_init!(let _wound_wait_class =
> > WwClass::new_wound_wait(c_str!("memory_pools"))); +/// +/// #
> > Ok::<(), Error>(()) +/// ```
> > +#[pin_data]
> > +pub struct WwClass {
> > +    /// Wrapper of the underlying C `ww_class`.
> > +    ///
> > +    /// You should not construct this type manually. Use the
> > `define_ww_class` macro
> > +    /// or call `WwClass::new_wait_die` or
> > `WwClass::new_wound_wait` instead.
> > +    #[pin]
> > +    pub inner: Opaque<bindings::ww_class>,
> 
> Why `pub`? Abstractions normally don't expose `Opaque` wrappers for
> bindings. Especially because this type is marked `#[pin_data]` this
> seems wrong, because this would allow people to construct it in a
> non-pinned state & also non-initialized state.

It was for `define_ww_class` macro. It obviously says you shouldn't do
that but sure, I can undo the `pub` and create a `const` function for
`define_ww_class`.


Regards,
Onur

  reply	other threads:[~2025-06-21 10:40 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-19 14:06 [PATCH V3] implement `ww_mutex` abstraction for the Rust tree Onur Özkan
2025-06-19 14:14 ` Peter Zijlstra
2025-06-19 14:33   ` Onur
2025-06-19 14:44     ` Alice Ryhl
2025-06-19 14:53       ` Peter Zijlstra
2025-06-19 18:59         ` Boqun Feng
2025-06-19 14:42 ` Benno Lossin
2025-06-21 10:32   ` Onur [this message]
2025-06-19 14:43 ` Benno Lossin

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=20250621133237.5ccdfa3a@nimda.home \
    --to=work@onurozkan.dev \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=dakr@kernel.org \
    --cc=gary@garyguo.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=lossin@kernel.org \
    --cc=mingo@redhat.com \
    --cc=ojeda@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=thatslyude@gmail.com \
    --cc=tmgross@umich.edu \
    --cc=will@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).