Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp4224757rwd; Tue, 30 May 2023 02:10:58 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ6MidbJgwvwpiNK9Tm4eZ3wTCtJXo4+88A1OkSeOAI5TgLI6fRXsW8C9pxv+tWYm06s6Gya X-Received: by 2002:a05:6a00:3913:b0:64f:4fdd:4152 with SMTP id fh19-20020a056a00391300b0064f4fdd4152mr1712253pfb.9.1685437858123; Tue, 30 May 2023 02:10:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685437858; cv=none; d=google.com; s=arc-20160816; b=JvXI3UHaFSnEvFWJCm4BjGGhK84UbEzvs5by5MKtqOAoEdQ2fCDWdu3jYQkOh/i6WI GIaFjUMkh6tNZCp4xSCJLv72F6ZbCtwkE3hz9XuVN8WqCj+hAOPjuBlbeck44acbbXZ4 QVOsoKo/xs60PC34dyLFAoFvbTS24pNFyiSmPlOAMYxY24C34y5b7pGcrm2eArDxUy2d rR3/s99PMnjCDQBYYspTzdsv7gZzOyC4w8Y/uhic1vLTkN3eTKKiXS426S+QaHwFPJkP sBLT0n/WkJ64jEr9n+mVMl+Lh8JczSNh6jb2zSNGXcZ9aThGthCoD1abN9fLGLhn9Vr7 SoDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:in-reply-to:date:subject :cc:to:from:user-agent:references:dkim-signature; bh=sKvmcYNdw0/e/A3ebTbEuUOu5G8ColBz5GGjZ4+9ndk=; b=nvNskK2gFIBW9/kvqfV5IjBYEjeR592FMzeun60O8kAiaAwcPTOrstpqf1ydigUlYb 3t3Bn3PGjCY9lg8KQ9+WfqNQn1LnANVDGClXBU/0Rv/or4xqHMypgBpXEk4NCsfiddfy iBgonA9uXEW2O7NufDMgl/izH+qFll+tWD6/g5aJ1NNBPyriOpNPVn93Lk9UpSk7YszU M3fP+VLED48o7N3eGwtfeMAfNrwqJIyG2RWlueVLyrRllQNYyze3N7GXN07f5BsxlH2c BEsN0UrHbc0qbQ2s0Pa4xtYlxRUee1m/hw1TyCUjvXT4vBoLvTFVpot3O0CqQewu9+8X njng== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@metaspace-dk.20221208.gappssmtp.com header.s=20221208 header.b=Vbdj6Kue; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q1-20020aa79821000000b00635ebd8854esi1406104pfl.173.2023.05.30.02.10.43; Tue, 30 May 2023 02:10:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@metaspace-dk.20221208.gappssmtp.com header.s=20221208 header.b=Vbdj6Kue; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229843AbjE3It7 (ORCPT + 99 others); Tue, 30 May 2023 04:49:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53808 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230306AbjE3It6 (ORCPT ); Tue, 30 May 2023 04:49:58 -0400 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E10EB100 for ; Tue, 30 May 2023 01:49:50 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-96fe88cd2fcso750591166b.1 for ; Tue, 30 May 2023 01:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metaspace-dk.20221208.gappssmtp.com; s=20221208; t=1685436589; x=1688028589; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:from:to:cc:subject:date:message-id:reply-to; bh=sKvmcYNdw0/e/A3ebTbEuUOu5G8ColBz5GGjZ4+9ndk=; b=Vbdj6KueAzHTkZQx/3tFSDLBLrmoaxp+qeJQG9Yx46L/72isRnbTSayQMxXE5a2Qra a5zdb0QoE/fzNwQ4jnZxAlF4X5+jd5LL8Bkd+brSrDz1oAg8PECciFTFDYCCm5Hqb8x9 LfIespmZFaroU1kKNOnHmWNBHeRPfN/v3ccMkLakbn3KtYdPO7TBKc/tUN+WjJrNNlIE Xg+4hf0POBYyhM/AHyHdLY4sC/7S9z1gWIujnWG6jHwFNciliYju7/bQ6wUNoeM9ecjw Wuhac5/GOYPEY0w4CVuK0+R3Ev8YfKxwV4PtTiuxsH0m1Oy7Bjw3XehRlxFwhZ1Jccrd nd1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685436589; x=1688028589; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=sKvmcYNdw0/e/A3ebTbEuUOu5G8ColBz5GGjZ4+9ndk=; b=La6n1zKfZQiK5bRUEK9eetv26QQcv0kWY36/pUTi5boyPQlF4K43dHAUgYbgk4i1QV H517bK5fehYsIVHTQ3fHuutVJjbpmdUVldiOsWJB9bA+jXr/0rRoGQDlmMhT6ZFheh82 hO6boY/sUm0ARsH6EzJ4qvD3OdkHfFr3BSPoyPRG7hffx/AQKUTkZZT88ldk7Slbc+Lf bbryQF6cb5H2oBNIegNwrDGLY0OdiVOODDz/enD6zr6E9/0Ffvbxcbg5RV5GUZF7XbS4 mXmzg7dfS/Fc9+Lt2mUWhBJ15JK9eLcTZHJr6SNkC5cH3kdVqik8fdbpR70MjxJOp4PM 19+w== X-Gm-Message-State: AC+VfDw6WTVO9wODFU5QcUQEw/0SO0T+/5usVL+53f3p81SnOu2qHAe2 Auuc+Eotv5reoRD1AfTlOMAQZw== X-Received: by 2002:a17:907:7e94:b0:96f:a935:8998 with SMTP id qb20-20020a1709077e9400b0096fa9358998mr1738140ejc.39.1685436589164; Tue, 30 May 2023 01:49:49 -0700 (PDT) Received: from localhost ([194.62.217.2]) by smtp.gmail.com with ESMTPSA id uz16-20020a170907119000b00965a56f82absm7058798ejb.212.2023.05.30.01.49.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 May 2023 01:49:48 -0700 (PDT) References: <20230517203119.3160435-1-aliceryhl@google.com> <20230517203119.3160435-6-aliceryhl@google.com> User-agent: mu4e 1.10.3; emacs 28.2.50 From: Andreas Hindborg To: Alice Ryhl Cc: rust-for-linux@vger.kernel.org, Miguel Ojeda , Wedson Almeida Filho , Tejun Heo , Lai Jiangshan , Alex Gaynor , Boqun Feng , Gary Guo , =?utf-8?Q?Bj=C3=B6rn?= Roy Baron , Benno Lossin , linux-kernel@vger.kernel.org, patches@lists.linux.dev Subject: Re: [PATCH v1 5/7] rust: workqueue: add helper for defining work_struct fields Date: Tue, 30 May 2023 10:44:19 +0200 In-reply-to: <20230517203119.3160435-6-aliceryhl@google.com> Message-ID: <87leh69par.fsf@metaspace.dk> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Alice Ryhl writes: > The main challenge with defining `work_struct` fields is making sure > that the function pointer stored in the `work_struct` is appropriate for > the work item type it is embedded in. It needs to know the offset of the > `work_struct` field being used (even if there are several!) so that it > can do a `container_of`, and it needs to know the type of the work item > so that it can call into the right user-provided code. All of this needs > to happen in a way that provides a safe API to the user, so that users > of the workqueue cannot mix up the function pointers. > > There are three important pieces that are relevant when doing this. This > commit will use traits so that they know about each other according to > the following cycle: > > * The pointer type. It knows the type of the work item struct. > * The work item struct. It knows the offset of its `work_struct` field. > * The `work_struct` field. It knows the pointer type. > > There's nothing special about making the pointer type know the type of > the struct it points at. Pointers generally always know that > information. > > However, making the `work_struct` field know about the pointer type is > less commonly seen. This is done by using a generic parameter: the > `work_struct` field will have the type `Work`, where T will be the > pointer type in use. The pointer type is required to implement the > `WorkItemAdapter` trait, which defines the function pointer to store in > the `work_struct` field. The `Work` type guarantees that the > `work_struct` inside it uses `::run` as its > function pointer. > > Finally, to make the work item struct know the offset of its > `work_struct` field, we use a trait called `HasWork`. If a type > implements this trait, then the type declares that, at the given offset, > there is a field of type `Work`. The trait is marked unsafe because > the OFFSET constant must be correct, but we provide an `impl_has_work!` > macro that can safely implement `HasWork` on a type. The macro > expands to something that only compiles if the specified field really > has the type `Work`. It is used like this: > > ``` > struct MyWorkItem { > work_field: Work>, > } > > impl_has_work! { > impl HasWork> for MyWorkItem { self.work_field } > } > ``` > > So to summarize, given a pointer to an allocation containing a work > item, you can use the `HasWork` trait to offset the pointer to the > `work_struct` field. The function pointer in the `work_struct` field is > guaranteed to be a function that knows what the original pointer type > was, and using that information, it can undo the offset operation by > looking up what the offset was via the `HasWork` trait. > > This design supports work items with multiple `work_struct` fields by > using different pointer types. For example, you might define structs > like these: > > ``` > struct MyPointer1(Arc); > struct MyPointer2(Arc); > > struct MyWorkItem { > work1: Work, > work2: Work, > } > ``` > > Then, the wrapper structs `MyPointer1` and `MyPointer2` will take the > role as the pointer type. By using one or the other, you tell the > workqueue which `work_struct` field to use. This pattern is called the > "newtype" pattern. > > Signed-off-by: Alice Ryhl > --- > rust/helpers.c | 8 ++ > rust/kernel/workqueue.rs | 183 ++++++++++++++++++++++++++++++++++++++- > 2 files changed, 190 insertions(+), 1 deletion(-) > > diff --git a/rust/helpers.c b/rust/helpers.c > index 81e80261d597..7f0c2fe2fbeb 100644 > --- a/rust/helpers.c > +++ b/rust/helpers.c > @@ -26,6 +26,7 @@ > #include > #include > #include > +#include > > __noreturn void rust_helper_BUG(void) > { > @@ -128,6 +129,13 @@ void rust_helper_put_task_struct(struct task_struct *t) > } > EXPORT_SYMBOL_GPL(rust_helper_put_task_struct); > > +void rust_helper___INIT_WORK(struct work_struct *work, work_func_t func, > + bool on_stack) > +{ > + __INIT_WORK(work, func, on_stack); > +} > +EXPORT_SYMBOL_GPL(rust_helper___INIT_WORK); > + > /* > * We use `bindgen`'s `--size_t-is-usize` option to bind the C `size_t` type > * as the Rust `usize` type, so we can use it in contexts where Rust > diff --git a/rust/kernel/workqueue.rs b/rust/kernel/workqueue.rs > index 22205d3bda72..7509618af252 100644 > --- a/rust/kernel/workqueue.rs > +++ b/rust/kernel/workqueue.rs > @@ -4,7 +4,8 @@ > //! > //! C header: [`include/linux/workqueue.h`](../../../../include/linux/workqueue.h) > > -use crate::{bindings, types::Opaque}; > +use crate::{bindings, prelude::*, types::Opaque}; > +use core::marker::{PhantomData, PhantomPinned}; > > /// A kernel work queue. > /// > @@ -98,6 +99,186 @@ pub unsafe trait WorkItem { > F: FnOnce(*mut bindings::work_struct) -> bool; > } > > +/// Defines the method that should be called when a work item is executed. > +/// > +/// This trait is used when the `work_struct` field is defined using the [`Work`] helper. > +/// > +/// # Safety > +/// > +/// Implementers must ensure that [`__enqueue`] uses a `work_struct` initialized with the [`run`] > +/// method of this trait as the function pointer. > +/// > +/// [`__enqueue`]: WorkItem::__enqueue > +/// [`run`]: WorkItemAdapter::run > +pub unsafe trait WorkItemAdapter: WorkItem { > + /// Run this work item. > + /// > + /// # Safety > + /// > + /// Must only be called via the function pointer that [`__enqueue`] provides to the > + /// `queue_work_on` closure, and only as described in the documentation of `queue_work_on`. > + /// > + /// [`__enqueue`]: WorkItem::__enqueue > + unsafe extern "C" fn run(ptr: *mut bindings::work_struct); > +} > + > +/// Links for a work item. > +/// > +/// This struct contains a function pointer to the `T::run` function from the [`WorkItemAdapter`] > +/// trait, and defines the linked list pointers necessary to enqueue a work item in a workqueue. > +/// > +/// Wraps the kernel's C `struct work_struct`. > +/// > +/// This is a helper type used to associate a `work_struct` with the [`WorkItemAdapter`] that uses > +/// it. > +#[repr(transparent)] > +pub struct Work { > + work: Opaque, > + _pin: PhantomPinned, > + _adapter: PhantomData, > +} > + > +// SAFETY: Kernel work items are usable from any thread. > +// > +// We do not need to constrain `T` since the work item does not actually contain a `T`. > +unsafe impl Send for Work {} > +// SAFETY: Kernel work items are usable from any thread. > +// > +// We do not need to constrain `T` since the work item does not actually contain a `T`. > +unsafe impl Sync for Work {} > + > +impl Work { > + /// Creates a new instance of [`Work`]. > + #[inline] > + #[allow(clippy::new_ret_no_self)] > + pub fn new() -> impl PinInit > + where > + T: WorkItemAdapter, > + { > + // SAFETY: The `WorkItemAdapter` implementation promises that `T::run` can be used as the > + // work item function. > + unsafe { > + kernel::init::pin_init_from_closure(move |slot| { > + bindings::__INIT_WORK(Self::raw_get(slot), Some(T::run), false); > + Ok(()) > + }) > + } > + } > + > + /// Get a pointer to the inner `work_struct`. > + /// > + /// # Safety > + /// > + /// The provided pointer must not be dangling. (But it need not be initialized.) > + #[inline] > + pub unsafe fn raw_get(ptr: *const Self) -> *mut bindings::work_struct { > + // SAFETY: The caller promises that the pointer is valid. > + // > + // A pointer cast would also be ok due to `#[repr(transparent)]`. We use `addr_of!` so that > + // the compiler does not complain that `work` is unused. > + unsafe { Opaque::raw_get(core::ptr::addr_of!((*ptr).work)) } > + } > +} > + > +/// Declares that a type has a [`Work`] field. > +/// > +/// # Safety > +/// > +/// The [`OFFSET`] constant must be the offset of a field in Self of type [`Work`]. The methods on > +/// this trait must have exactly the behavior that the definitions given below have. > +/// > +/// [`Work`]: Work > +/// [`OFFSET`]: HasWork::OFFSET > +pub unsafe trait HasWork { > + /// The offset of the [`Work`] field. > + /// > + /// [`Work`]: Work > + const OFFSET: usize; > + > + /// Returns the offset of the [`Work`] field. > + /// > + /// This method exists because the [`OFFSET`] constant cannot be accessed if the type is not Sized. > + /// > + /// [`Work`]: Work > + /// [`OFFSET`]: HasWork::OFFSET > + #[inline] > + fn get_work_offset(&self) -> usize { > + Self::OFFSET > + } > + > + /// Returns a pointer to the [`Work`] field. > + /// > + /// # Safety > + /// > + /// The pointer must not be dangling. (But the memory need not be initialized.) > + /// > + /// [`Work`]: Work > + #[inline] > + unsafe fn raw_get_work(ptr: *mut Self) -> *mut Work > + where > + Self: Sized, > + { > + // SAFETY: The caller promises that the pointer is not dangling. > + unsafe { (ptr as *mut u8).add(Self::OFFSET) as *mut Work } > + } > + > + /// Returns a pointer to the struct containing the [`Work`] field. > + /// > + /// # Safety > + /// > + /// The pointer must not be dangling. (But the memory need not be initialized.) > + /// > + /// [`Work`]: Work > + #[inline] > + unsafe fn work_container_of(ptr: *mut Work) -> *mut Self > + where > + Self: Sized, > + { > + // SAFETY: The caller promises that the pointer is not dangling. > + unsafe { (ptr as *mut u8).sub(Self::OFFSET) as *mut Self } > + } > +} > + > +/// Used to safely implement the [`HasWork`] trait. > +/// > +/// # Examples > +/// > +/// ``` > +/// use kernel::sync::Arc; > +/// > +/// struct MyStruct { > +/// work_field: Work>, > +/// } > +/// > +/// impl_has_work! { > +/// impl HasWork> for MyStruct { self.work_field } > +/// } > +/// ``` > +/// > +/// [`HasWork`]: HasWork > +#[macro_export] > +macro_rules! impl_has_work { > + ($(impl$(<$($implarg:ident),*>)? > + HasWork<$work_type:ty> > + for $self:ident $(<$($selfarg:ident),*>)? > + { self.$field:ident } > + )*) => {$( > + // SAFETY: The implementation of `raw_get_work` only compiles if the field has the right > + // type. > + unsafe impl$(<$($implarg),*>)? $crate::workqueue::HasWork<$work_type> for $self $(<$($selfarg),*>)? { > + const OFFSET: usize = $crate::offset_of!(Self, $field) as usize; > + > + #[inline] > + unsafe fn raw_get_work(ptr: *mut Self) -> *mut $crate::workqueue::Work<$work_type> { > + // SAFETY: The caller promises that the pointer is not dangling. > + unsafe { > + ::core::ptr::addr_of_mut!((*ptr).$field) > + } > + } What is the reason for overriding the default implementation of `raw_get_work()`? BR Andreas > + } > + )*}; > +} > + > /// Returns the system work queue (`system_wq`). > /// > /// It is the one used by `schedule[_delayed]_work[_on]()`. Multi-CPU multi-threaded. There are