All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alice Ryhl <aliceryhl@google.com>
To: Benno Lossin <lossin@kernel.org>
Cc: "Christian Schrefl" <chrisi.schrefl@gmail.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Lee Jones" <lee@kernel.org>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Gerald Wisböck" <gerald.wisboeck@feather.ink>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/3] rust: miscdevice: add additional data to MiscDeviceRegistration
Date: Wed, 4 Jun 2025 09:37:56 +0000	[thread overview]
Message-ID: <aEAT9B669Qvi0rlR@google.com> (raw)
In-Reply-To: <DAACCYW3QRQE.1O75L2SHJYVPM@kernel.org>

On Sat, May 31, 2025 at 02:23:23PM +0200, Benno Lossin wrote:
> On Fri May 30, 2025 at 10:46 PM CEST, Christian Schrefl wrote:
> > @@ -45,32 +46,46 @@ pub const fn into_raw<T: MiscDevice>(self) -> bindings::miscdevice {
> >  /// # Invariants
> >  ///
> >  /// `inner` is a registered misc device.
> > -#[repr(transparent)]
> > +#[repr(C)]
> 
> Why do we need linear layout? `container_of!` also works with the `Rust`
> layout.
> 
> >  #[pin_data(PinnedDrop)]
> > -pub struct MiscDeviceRegistration<T> {
> > +pub struct MiscDeviceRegistration<T: MiscDevice> {
> >      #[pin]
> >      inner: Opaque<bindings::miscdevice>,
> > +    #[pin]
> > +    data: Opaque<T::RegistrationData>,
> >      _t: PhantomData<T>,
> 
> No need to keep the `PhantomData` field around, since you're using `T`
> above.
> 
> >  }
> >  
> > -// SAFETY: It is allowed to call `misc_deregister` on a different thread from where you called
> > -// `misc_register`.
> > -unsafe impl<T> Send for MiscDeviceRegistration<T> {}
> > -// SAFETY: All `&self` methods on this type are written to ensure that it is safe to call them in
> > -// parallel.
> > -unsafe impl<T> Sync for MiscDeviceRegistration<T> {}
> > +// SAFETY:
> > +// - It is allowed to call `misc_deregister` on a different thread from where you called
> > +//   `misc_register`.
> > +// - Only implements `Send` if `MiscDevice::RegistrationData` is also `Send`.
> > +unsafe impl<T: MiscDevice> Send for MiscDeviceRegistration<T> where T::RegistrationData: Send {}
> > +
> > +// SAFETY:
> > +// - All `&self` methods on this type are written to ensure that it is safe to call them in
> > +//   parallel.
> > +// - `MiscDevice::RegistrationData` is always `Sync`.
> > +unsafe impl<T: MiscDevice> Sync for MiscDeviceRegistration<T> {}
> 
> I would feel better if we still add the `T::RegistrationData: Sync`
> bound here even if it is vacuous today.
> 
> >  impl<T: MiscDevice> MiscDeviceRegistration<T> {
> >      /// Register a misc device.
> > -    pub fn register(opts: MiscDeviceOptions) -> impl PinInit<Self, Error> {
> > +    pub fn register(
> > +        opts: MiscDeviceOptions,
> > +        data: impl PinInit<T::RegistrationData, Error>,
> > +    ) -> impl PinInit<Self, Error> {
> >          try_pin_init!(Self {
> > +            data <- Opaque::pin_init(data),
> >              inner <- Opaque::try_ffi_init(move |slot: *mut bindings::miscdevice| {
> >                  // SAFETY: The initializer can write to the provided `slot`.
> >                  unsafe { slot.write(opts.into_raw::<T>()) };
> >  
> > -                // SAFETY: We just wrote the misc device options to the slot. The miscdevice will
> > -                // get unregistered before `slot` is deallocated because the memory is pinned and
> > -                // the destructor of this type deallocates the memory.
> > +                // SAFETY:
> > +                // * We just wrote the misc device options to the slot. The miscdevice will
> > +                //   get unregistered before `slot` is deallocated because the memory is pinned and
> > +                //   the destructor of this type deallocates the memory.
> > +                // * `data` is Initialized before `misc_register` so no race with `fops->open()`
> > +                //   is possible.
> >                  // INVARIANT: If this returns `Ok(())`, then the `slot` will contain a registered
> >                  // misc device.
> >                  to_result(unsafe { bindings::misc_register(slot) })
> > @@ -93,13 +108,24 @@ pub fn device(&self) -> &Device {
> >          // before the underlying `struct miscdevice` is destroyed.
> >          unsafe { Device::as_ref((*self.as_raw()).this_device) }
> >      }
> > +
> > +    /// Access the additional data stored in this registration.
> > +    pub fn data(&self) -> &T::RegistrationData {
> > +        // SAFETY:
> > +        // * No mutable reference to the value contained by `self.data` can ever be created.
> > +        // * The value contained by `self.data` is valid for the entire lifetime of `&self`.
> 
> Please add type invariants for these two requirements.
> 
> > +        unsafe { &*self.data.get() }
> > +    }
> >  }
> >  
> >  #[pinned_drop]
> > -impl<T> PinnedDrop for MiscDeviceRegistration<T> {
> > +impl<T: MiscDevice> PinnedDrop for MiscDeviceRegistration<T> {
> >      fn drop(self: Pin<&mut Self>) {
> >          // SAFETY: We know that the device is registered by the type invariants.
> >          unsafe { bindings::misc_deregister(self.inner.get()) };
> > +
> > +        // SAFETY: `self.data` is valid for dropping and nothing uses it anymore.
> 
> Ditto.
> 
> > +        unsafe { core::ptr::drop_in_place(self.data.get()) };
> >      }
> >  }
> >  
> > @@ -109,6 +135,13 @@ pub trait MiscDevice: Sized {
> >      /// What kind of pointer should `Self` be wrapped in.
> >      type Ptr: ForeignOwnable + Send + Sync;
> >  
> > +    /// The additional data carried by the [`MiscDeviceRegistration`] for this [`MiscDevice`].
> > +    /// If no additional data is required than the unit type `()` should be used.
> > +    ///
> > +    /// This data can be accessed in [`MiscDevice::open()`] using
> > +    /// [`MiscDeviceRegistration::data()`].
> > +    type RegistrationData: Sync;
> 
> Why do we require `Sync` here?
> 
> We might want to give this a shorter name?



  parent reply	other threads:[~2025-06-04  9:38 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-30 20:46 [PATCH v4 0/3] rust: miscdevice: add additional data to MiscDeviceRegistration Christian Schrefl
2025-05-30 20:46 ` [PATCH v4 1/3] rust: implement `Wrapper<T>` for `Opaque<T>` Christian Schrefl
2025-05-30 20:53   ` Christian Schrefl
2025-05-30 21:43     ` Danilo Krummrich
2025-05-30 20:46 ` [PATCH v4 2/3] rust: miscdevice: add additional data to MiscDeviceRegistration Christian Schrefl
2025-05-31 12:23   ` Benno Lossin
2025-06-02 21:16     ` Christian Schrefl
2025-06-03 23:29       ` Benno Lossin
2025-06-04  8:48         ` Miguel Ojeda
2025-06-04  9:54           ` Christian Schrefl
2025-06-04 10:13             ` Miguel Ojeda
2025-06-05 14:57         ` Christian Schrefl
2025-06-05 16:05           ` Benno Lossin
2025-06-05 16:52             ` Christian Schrefl
2025-06-05 17:27               ` Benno Lossin
2025-06-07 11:34                 ` Christian Schrefl
2025-06-07 15:37                   ` Benno Lossin
2025-06-07 15:39                     ` Christian Schrefl
2025-06-07 19:05                       ` Benno Lossin
2025-06-04  9:40       ` Alice Ryhl
2025-06-04  9:42         ` Christian Schrefl
2025-06-04  9:43           ` Alice Ryhl
2025-06-04  9:37     ` Alice Ryhl [this message]
2025-06-04  9:41       ` Alice Ryhl
2025-05-30 20:46 ` [PATCH v4 3/3] rust: miscdevice: adjust the rust_misc_device sample to use RegistrationData Christian Schrefl
2025-05-31 12:27   ` Benno Lossin
2025-05-31 13:40     ` Miguel Ojeda
2025-06-02 21:20       ` Christian Schrefl

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=aEAT9B669Qvi0rlR@google.com \
    --to=aliceryhl@google.com \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=arnd@arndb.de \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=chrisi.schrefl@gmail.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=gary@garyguo.net \
    --cc=gerald.wisboeck@feather.ink \
    --cc=gregkh@linuxfoundation.org \
    --cc=lee@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.