From: "Benno Lossin" <lossin@kernel.org>
To: "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>,
"Alice Ryhl" <aliceryhl@google.com>,
"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>
Cc: "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: Sat, 31 May 2025 14:23:23 +0200 [thread overview]
Message-ID: <DAACCYW3QRQE.1O75L2SHJYVPM@kernel.org> (raw)
In-Reply-To: <20250530-b4-rust_miscdevice_registrationdata-v4-2-d313aafd7e59@gmail.com>
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?
---
Cheers,
Benno
> +
> /// Called when the misc device is opened.
> ///
> /// The returned pointer will be stored as the private data for the file.
next prev parent reply other threads:[~2025-05-31 12:23 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 [this message]
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
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=DAACCYW3QRQE.1O75L2SHJYVPM@kernel.org \
--to=lossin@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.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=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 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).