All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alice Ryhl <aliceryhl@google.com>
To: "Onur Özkan" <work@onurozkan.dev>
Cc: rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
	 ojeda@kernel.org, boqun@kernel.org, gary@garyguo.net,
	 bjorn3_gh@protonmail.com, lossin@kernel.org,
	a.hindborg@kernel.org,  tmgross@umich.edu, dakr@kernel.org,
	tamird@kernel.org,  daniel.almeida@collabora.com
Subject: Re: [PATCH v2 1/1] rust: workqueue: add cancel_sync support
Date: Mon, 15 Jun 2026 07:08:37 +0000	[thread overview]
Message-ID: <ai-k9as5Vfvq2bjs@google.com> (raw)
In-Reply-To: <20260612194633.350011-2-work@onurozkan.dev>

On Fri, Jun 12, 2026 at 10:45:42PM +0300, Onur Özkan wrote:
> Drivers can use this during teardown to cancel pending work and wait for
> running work to finish before dropping related resources.
> 
> This is not implemented for Pin<KBox<T>> because queuing a boxed work
> item transfers ownership of the box to the workqueue. There is therefore
> no separate safe owner that can cancel the boxed work while it is pending.
> 
> Signed-off-by: Onur Özkan <work@onurozkan.dev>

Overall looks reasonable to me, but some comments below.

>  rust/kernel/workqueue.rs | 116 +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 116 insertions(+)
> 
> diff --git a/rust/kernel/workqueue.rs b/rust/kernel/workqueue.rs
> index 7e253b6f299c..4d61d7a10fae 100644
> --- a/rust/kernel/workqueue.rs
> +++ b/rust/kernel/workqueue.rs
> @@ -471,6 +471,23 @@ pub trait WorkItem<const ID: u64 = 0> {
>      fn run(this: Self::Pointer);
>  }
>  
> +/// Work item pointers that support cancellation.
> +///
> +/// # Safety
> +///
> +/// Implementers must ensure that `from_raw_work` rebuilds the exact ownership transferred
> +/// by a successful [`RawWorkItem::__enqueue`] call.
> +pub unsafe trait SupportsCancelling<const ID: u64>: WorkItemPointer<ID> + Sized {

Nit; I think it reads nicer as SupportsCancel.

> +    /// Rebuild this work item's pointer from its embedded `work_struct`.
> +    ///
> +    /// # Safety
> +    ///
> +    /// The provided `work_struct` pointer must originate from a previous call to
> +    /// [`RawWorkItem::__enqueue`] where the `queue_work_on` closure returned true
> +    /// and the pointer must still be valid.
> +    unsafe fn from_raw_work(ptr: *mut bindings::work_struct) -> Self;

I think you're missing some condition here about ownership having been
transferred *out* from the workqueue by cancel_sync() or similar
methods. Otherwise this currently says I can call the method even though
the workqueue still owns the work item.

> +    /// # Note
> +    ///
> +    /// Should be called from a sleepable context if the work was last queued on a non-BH
> +    /// workqueue.

Nit: I'd either reword "Note" to something more specific to what the
note is about, or remove the heading.

> +    #[inline]
> +    pub fn cancel_sync(&self) -> Option<T::Pointer>
> +    where
> +        T: WorkItem<ID>,
> +        T::Pointer: SupportsCancelling<ID>,
> +    {
> +        let ptr = self.dwork.get();
> +
> +        // SAFETY: `ptr` is a valid embedded `delayed_work`.
> +        if unsafe { bindings::cancel_delayed_work_sync(ptr) } {
> +            // SAFETY: A `true` return means the work was pending and got canceled, so the queued
> +            // ownership transfer performed by `__enqueue` is reclaimed here.
> +            Some(unsafe { T::Pointer::from_raw_work(core::ptr::addr_of_mut!((*ptr).work)) })

Nit: The addr_of_mut! macro is no longer required. You can do: &raw mut (*ptr).work

Alice

      reply	other threads:[~2026-06-15  7:08 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-12 19:45 [PATCH v2 0/1] rust: workqueue: add cancel_sync support Onur Özkan
2026-06-12 19:45 ` [PATCH v2 1/1] " Onur Özkan
2026-06-15  7:08   ` Alice Ryhl [this message]

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=ai-k9as5Vfvq2bjs@google.com \
    --to=aliceryhl@google.com \
    --cc=a.hindborg@kernel.org \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=gary@garyguo.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tamird@kernel.org \
    --cc=tmgross@umich.edu \
    --cc=work@onurozkan.dev \
    /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.