linux-kernel - Re: [PATCH 1/3] rust: completion: implement initial abstraction

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aEqwQYJdbVSNA7mr@pollux>
Date: Thu, 12 Jun 2025 12:47:29 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Benno Lossin <lossin@...nel.org>
Cc: gregkh@...uxfoundation.org, rafael@...nel.org, ojeda@...nel.org,
	alex.gaynor@...il.com, boqun.feng@...il.com, gary@...yguo.net,
	bjorn3_gh@...tonmail.com, benno.lossin@...ton.me,
	a.hindborg@...nel.org, aliceryhl@...gle.com, tmgross@...ch.edu,
	chrisi.schrefl@...il.com, rust-for-linux@...r.kernel.org,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Juri Lelli <juri.lelli@...hat.com>,
	Vincent Guittot <vincent.guittot@...aro.org>,
	Dietmar Eggemann <dietmar.eggemann@....com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
	Valentin Schneider <vschneid@...hat.com>
Subject: Re: [PATCH 1/3] rust: completion: implement initial abstraction

On Thu, Jun 12, 2025 at 09:58:30AM +0200, Benno Lossin wrote:
> On Tue Jun 3, 2025 at 10:48 PM CEST, Danilo Krummrich wrote:
> > +/// # Examples
> > +///
> > +/// ```
> > +/// use kernel::sync::{Arc, Completion};
> > +/// use kernel::workqueue::{self, impl_has_work, new_work, Work, WorkItem};
> > +///
> > +/// #[pin_data]
> > +/// struct MyTask {
> > +///     #[pin]
> > +///     work: Work<MyTask>,
> 
> Can we maybe add a dummy value like `Mutex<i32>` here that the task
> changes, so we can print the value of it below (after waiting for the
> task)?

Sure, but I don't think it improves the example a lot. It adds more code that
may be more distracting than helpful.

> > +///     #[pin]
> > +///     done: Completion,
> > +/// }
> > +///
> > +/// impl_has_work! {
> > +///     impl HasWork<Self> for MyTask { self.work }
> > +/// }
> > +///
> > +/// impl MyTask {
> > +///     fn new() -> Result<Arc<Self>> {
> > +///         let this = Arc::pin_init(pin_init!(MyTask {
> > +///             work <- new_work!("MyTask::work"),
> > +///             done <- Completion::new(),
> > +///         }), GFP_KERNEL)?;
> > +///
> > +///         let _ = workqueue::system().enqueue(this.clone());
> > +///
> > +///         Ok(this)
> > +///     }
> > +///
> > +///     fn wait_for_completion(&self) {
> > +///         self.done.wait_for_completion();
> > +///
> > +///         pr_info!("Completion: task complete\n");
> > +///     }
> > +/// }
> > +///
> > +/// impl WorkItem for MyTask {
> > +///     type Pointer = Arc<MyTask>;
> > +///
> > +///     fn run(this: Arc<MyTask>) {
> > +///         // process this task
> > +///         this.done.complete_all();
> > +///     }
> > +/// }
> > +///
> > +/// let task = MyTask::new()?;
> > +/// task.wait_for_completion();
> > +/// # Ok::<(), Error>(())
> > +/// ```
> > +#[pin_data]
> > +pub struct Completion {
> > +    #[pin]
> > +    inner: Opaque<bindings::completion>,
> > +}
> > +
> > +impl Completion {
> > +    /// Create an initializer for a new [`Completion`].
> > +    pub fn new() -> impl PinInit<Self> {
> > +        pin_init!(Self {
> > +            inner <- Opaque::ffi_init(|slot: *mut bindings::completion| {
> > +                // SAFETY: `slot` is a valid pointer to an uninitialized `struct completion`.
> > +                unsafe { bindings::init_completion(slot) };
> > +            }),
> > +        })
> > +    }
> > +
> > +    fn as_raw(&self) -> *mut bindings::completion {
> > +        self.inner.get()
> > +    }
> > +
> > +    /// Signal all tasks waiting on this completion.
> > +    ///
> > +    /// This method wakes up all tasks waiting on this completion; after this operation the
> > +    /// completion is permanently done.
> > +    pub fn complete_all(&self) {
> > +        // SAFETY: `self.as_raw()` is a pointer to a valid `struct completion`.
> > +        unsafe { bindings::complete_all(self.as_raw()) };
> > +    }
> > +
> > +    /// Wait for completion of a task.
> > +    ///
> > +    /// This method waits for the completion of a task; it is not interruptible and there is no
> 
> I personally would write:
> 
> s/waits for/blocks on/
> 
> But if `wait` is the more common kernel term then let's go with your
> version instead.

I don't think either is more common in general, but the C code and the existing
documentation all use "wait for".