From: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
To: Alice Ryhl <aliceryhl@google.com>, rust-for-linux@vger.kernel.org
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Wedson Almeida Filho" <wedsonaf@gmail.com>,
"Tejun Heo" <tj@kernel.org>,
"Lai Jiangshan" <jiangshanlai@gmail.com>,
"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>,
"Benno Lossin" <benno.lossin@proton.me>,
linux-kernel@vger.kernel.org, patches@lists.linux.dev
Subject: Re: [PATCH v1 6/7] rust: workqueue: add safe API to workqueue
Date: Thu, 18 May 2023 21:17:21 -0300 [thread overview]
Message-ID: <b54801cd-1afb-2190-3b8a-4a095d04fdff@gmail.com> (raw)
In-Reply-To: <20230517203119.3160435-7-aliceryhl@google.com>
On 5/17/23 17:31, Alice Ryhl wrote:
> This commit introduces `ArcWorkItem`, `BoxWorkItem`, and
> `define_work_adapter_newtype!` that make it possible to use the
> workqueue without any unsafe code whatsoever.
>
> The `ArcWorkItem` and `BoxWorkItem` traits are used when a struct has a
> single `work_struct` field.
>
> The `define_work_adapter_newtype!` macro is used when a struct has
> multiple `work_struct` fields. For each `work_struct` field, a newtype
> struct is defined that wraps `Arc<TheStruct>`, and pushing an instance
> of the newtype to a workqueue will enqueue it using the associated
> `work_struct` field. The newtypes are matched with `work_struct` fields
> by having the T in `Work<T>` be the newtype.
>
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
> [...]
> +
> +unsafe impl<T> WorkItem for Arc<T>
> +where
> + T: ArcWorkItem + HasWork<Self> + ?Sized,
> +{
> + type EnqueueOutput = Result<(), Self>;
> +
> + unsafe fn __enqueue<F>(self, queue_work_on: F) -> Self::EnqueueOutput
> + where
> + F: FnOnce(*mut bindings::work_struct) -> bool,
> + {
> + let ptr = Arc::into_raw(self);
> +
> + // Using `get_work_offset` here for object-safety.
> + //
> + // SAFETY: The pointer is valid since we just got it from `into_raw`.
> + let off = unsafe { (&*ptr).get_work_offset() };
> +
> + // SAFETY: The `HasWork` impl promises that this offset gives us a field of type
> + // `Work<Self>` in the same allocation.
> + let work_ptr = unsafe { (ptr as *const u8).add(off) as *const Work<Self> };
> + // SAFETY: The pointer is not dangling.
> + let work_ptr = unsafe { Work::raw_get(work_ptr) };
> +
> + match (queue_work_on)(work_ptr) {
Match for boolean is not a good pattern in my eyes, if-else should be
used instead. Also aren't the parens around the closure unnecessary?
> + true => Ok(()),
> + // SAFETY: The work queue has not taken ownership of the pointer.
> + false => Err(unsafe { Arc::from_raw(ptr) }),
> + }
> + }
> +}
> +
> [...]
> +
> +unsafe impl<T> WorkItem for Pin<Box<T>>
> +where
> + T: BoxWorkItem + HasWork<Self> + ?Sized,
> +{
> + // When a box is in a workqueue, the workqueue has exclusive ownership of the box. Therefore,
> + // it's not possible to enqueue a box while it is in a workqueue.
> + type EnqueueOutput = ();
> +
> + unsafe fn __enqueue<F>(self, queue_work_on: F)
> + where
> + F: FnOnce(*mut bindings::work_struct) -> bool,
> + {
> + // SAFETY: We will not used the contents in an unpinned manner.
> + let ptr = unsafe { Box::into_raw(Pin::into_inner_unchecked(self)) };
> +
> + // Using `get_work_offset` here for object-safety.
> + //
> + // SAFETY: The pointer is valid since we just got it from `into_raw`.
> + let off = unsafe { (&*ptr).get_work_offset() };
> +
> + // SAFETY: The `HasWork` impl promises that this offset gives us a field of type
> + // `Work<Self>` in the same allocation.
> + let work_ptr = unsafe { (ptr as *mut u8).add(off) as *mut Work<Self> };
> + // SAFETY: The pointer is not dangling.
> + let work_ptr = unsafe { Work::raw_get(work_ptr) };
> +
> + match (queue_work_on)(work_ptr) {
Same as above.
> + true => {}
> + // SAFETY: This method requires exclusive ownership of the box, so it cannot be in a
> + // workqueue.
> + false => unsafe { core::hint::unreachable_unchecked() },
> + }
> + }
> +}
> +
> [...]
> +
> +/// Helper macro for structs with several `Work` fields that can be in several queues at once.
> +///
> +/// For each `Work` field in your type `T`, a newtype struct that wraps an `Arc<T>` or
> +/// `Pin<Box<T>>` should be defined.
> +///
> +/// # Examples
> +///
> +/// ```
There must be those work macro and type imports here I think.
> +/// struct MyStruct {
> +/// work1: Work<MyStructWork1>,
> +/// work2: Work<MyStructWork2>,
> +/// }
> +///
> +/// impl_has_work! {
> +/// impl HasWork<MyStructWork1> for MyStruct { self.work1 }
> +/// impl HasWork<MyStructWork2> for MyStruct { self.work2 }
> +/// }
> +///
> +/// define_work_adapter_newtype! {
> +/// struct MyStructWork1(Arc<MyStruct>);
> +/// struct MyStructWork2(Arc<MyStruct>);
> +/// }
> +///
> +/// impl MyStructWork1 {
> +/// fn run(self) {
> +/// // ...
> +/// }
> +/// }
> +///
> +/// impl MyStructWork2 {
> +/// fn run(self) {
> +/// // ...
> +/// }
> +/// }
> +/// ```
> +///
> +/// This will let you push a `MyStructWork1(arc)` or `MyStructWork2(arc)` to a work queue. The [`Arc`]
> +/// can be in two work queues at the same time, and the `run` method on the wrapper type is called
> +/// when the work item is called.
> +///
> +/// [`Arc`]: crate::sync::Arc
> +#[macro_export]
> +macro_rules! define_work_adapter_newtype {
> + (
> + $(#[$outer:meta])*
> + $pub:vis struct $name:ident(
> + $(#[$innermeta:meta])*
> + $fpub:vis Arc<$inner:ty> $(,)?
> + );
> + $($rest:tt)*
> + ) => {
> + $(#[$outer])*
> + $pub struct $name($(#[$innermeta])* $fpub $crate::sync::Arc<$inner>);
> +
> + unsafe impl $crate::workqueue::WorkItem for $name {
> + type EnqueueOutput = ::core::result::Result<(), $name>;
> +
> + unsafe fn __enqueue<F>(self, queue_work_on: F) -> Self::EnqueueOutput
> + where
> + F: ::core::ops::FnOnce(*mut $crate::bindings::work_struct) -> bool,
> + {
> + let ptr = $crate::sync::Arc::into_raw(self.0);
> +
> + // SAFETY: The pointer is not dangling since we just got it from Arc::into_raw.
> + let work_ptr = unsafe { <$inner as $crate::workqueue::HasWork::<$name>>::raw_get_work(ptr.cast_mut()) };
> +
> + // SAFETY: The pointer is not dangling.
> + let work_ptr = unsafe { $crate::workqueue::Work::raw_get(work_ptr) };
> +
> + match (queue_work_on)(work_ptr) {
Same as what I've said on those `WorkItem` impls.
> + true => Ok(()),
> + // SAFETY: The work queue has not taken ownership of the pointer.
> + false => Err($name(unsafe { $crate::sync::Arc::from_raw(ptr) })),
> + }
> + }
> + }
> [...]
> + };
> +
> + (
> + $(#[$outer:meta])*
> + $pub:vis struct $name:ident(
> + $(#[$innermeta:meta])*
> + $fpub:vis Pin<Box<$inner:ty>> $(,)?
> + );
> + $($rest:tt)*
> + ) => {
> + $(#[$outer])*
> + $pub struct $name($(#[$innermeta])* $fpub ::core::pin::Pin<::alloc::boxed::Box<$inner>>);
> +
> + unsafe impl $crate::workqueue::WorkItem for $name {
> + type EnqueueOutput = ();
> +
> + unsafe fn __enqueue<F>(self, queue_work_on: F)
> + where
> + F: ::core::ops::FnOnce(*mut $crate::bindings::work_struct) -> bool,
> + {
> + // SAFETY: We will not used the contents in an unpinned manner.
> + let boxed = unsafe { ::core::pin::Pin::into_inner_unchecked(self.0) };
> + let ptr = ::alloc::boxed::Box::into_raw(boxed);
> +
> + // SAFETY: The pointer is not dangling since we just got it from Box::into_raw.
> + let work_ptr = unsafe { <$inner as $crate::workqueue::HasWork::<$name>>::raw_get_work(ptr) };
> +
> + // SAFETY: The pointer is not dangling.
> + let work_ptr = unsafe { $crate::workqueue::Work::raw_get(work_ptr) };
> +
> + match (queue_work_on)(work_ptr) {
Same as above.
> + true => {},
> + // SAFETY: This method requires exclusive ownership of the box, so it cannot be in a
> + // workqueue.
> + false => unsafe { ::core::hint::unreachable_unchecked() },
> + }
> + }
> + }
> +
> [...]
next prev parent reply other threads:[~2023-05-19 0:29 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-17 20:31 [PATCH v1 0/7] Bindings for the workqueue Alice Ryhl
2023-05-17 20:31 ` [PATCH v1 1/7] rust: workqueue: add low-level workqueue bindings Alice Ryhl
2023-05-18 14:51 ` Martin Rodriguez Reboredo
2023-05-19 9:40 ` Alice Ryhl
2023-05-19 12:04 ` Martin Rodriguez Reboredo
2023-05-23 10:03 ` Alice Ryhl
2023-05-30 8:26 ` Andreas Hindborg
2023-05-17 20:31 ` [PATCH v1 2/7] rust: add offset_of! macro Alice Ryhl
2023-05-18 14:51 ` Martin Rodriguez Reboredo
2023-05-23 15:48 ` Gary Guo
2023-05-24 12:26 ` Alice Ryhl
2023-05-30 8:40 ` Andreas Hindborg
2023-05-17 20:31 ` [PATCH v1 3/7] rust: sync: add `Arc::{from_raw, into_raw}` Alice Ryhl
2023-05-18 14:51 ` Martin Rodriguez Reboredo
2023-05-23 15:43 ` Gary Guo
2023-05-24 11:19 ` Alice Ryhl
2023-05-24 10:20 ` Andreas Hindborg
2023-05-24 11:11 ` Alice Ryhl
2023-05-25 7:45 ` Andreas Hindborg
2023-05-25 16:32 ` Gary Guo
2023-05-30 7:23 ` Andreas Hindborg
2023-05-17 20:31 ` [PATCH v1 4/7] rust: workqueue: define built-in queues Alice Ryhl
2023-05-18 14:52 ` Martin Rodriguez Reboredo
2023-05-25 11:40 ` Andreas Hindborg
2023-05-31 14:02 ` Alice Ryhl
2023-06-02 10:23 ` Andreas Hindborg (Samsung)
2023-05-17 20:31 ` [PATCH v1 5/7] rust: workqueue: add helper for defining work_struct fields Alice Ryhl
2023-05-18 23:18 ` Martin Rodriguez Reboredo
2023-05-24 14:50 ` Benno Lossin
2023-05-30 8:44 ` Andreas Hindborg
2023-05-31 9:00 ` Alice Ryhl
2023-05-31 10:18 ` Andreas Hindborg
2023-05-17 20:31 ` [PATCH v1 6/7] rust: workqueue: add safe API to workqueue Alice Ryhl
2023-05-19 0:17 ` Martin Rodriguez Reboredo [this message]
2023-05-23 11:07 ` Alice Ryhl
2023-05-30 7:19 ` Andreas Hindborg
2023-05-30 13:23 ` Martin Rodriguez Reboredo
2023-05-30 14:13 ` Miguel Ojeda
2023-05-24 14:51 ` Benno Lossin
2023-05-31 9:07 ` Alice Ryhl
2023-05-30 8:51 ` Andreas Hindborg
2023-05-31 14:07 ` Alice Ryhl
2023-05-17 20:31 ` [PATCH v1 7/7] rust: workqueue: add `try_spawn` helper method Alice Ryhl
2023-05-18 6:15 ` kernel test robot
2023-05-19 0:22 ` Martin Rodriguez Reboredo
2023-05-22 9:39 ` kernel test robot
2023-05-24 14:52 ` Benno Lossin
2023-05-31 14:03 ` Alice Ryhl
2023-05-17 21:48 ` [PATCH v1 0/7] Bindings for the workqueue Tejun Heo
2023-05-17 22:22 ` Alice Ryhl
2023-05-23 14:08 ` Andreas Hindborg
2023-05-23 14:14 ` Andreas Hindborg
2023-05-24 12:33 ` Alice Ryhl
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=b54801cd-1afb-2190-3b8a-4a095d04fdff@gmail.com \
--to=yakoyoku@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=jiangshanlai@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=patches@lists.linux.dev \
--cc=rust-for-linux@vger.kernel.org \
--cc=tj@kernel.org \
--cc=wedsonaf@gmail.com \
/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.