Re: [PATCH v2 6/6] rust: workqueue: add ScopedWork for non-'static work items

From: Daniel Almeida

Date: Thu Aug 27 2026 - 19:08:05 EST


>
> /// Creates a [`Work`] initialiser with the given name and a newly-created lock class.
> #[macro_export]
> @@ -283,23 +289,39 @@ pub unsafe fn from_raw<'a>(ptr: *const bindings::workqueue_struct) -> &'a Queue
> /// This may fail if the work item is already enqueued in a workqueue.
> ///
> /// The work item will be submitted using `WORK_CPU_UNBOUND`.
> + #[inline]
> pub fn enqueue<W, const ID: u64>(&self, w: W) -> W::EnqueueOutput
> where
> W: RawWorkItem<ID> + Send + 'static,
> + {
> + // SAFETY: `W: 'static` guarantees the work item remains valid indefinitely,
> + // so the `enqueue_scoped` requirement that the work item stays valid until
> + // the work function runs (or is cancelled) is trivially satisfied.
> + unsafe { self.enqueue_scoped(w) }
> + }
> +
> + /// Enqueues a work item that may not be `'static`.
> + ///
> + /// Unlike [`Queue::enqueue`], this does not require the work item to be `'static`.
> + ///
> + /// The work item will be submitted using `WORK_CPU_UNBOUND`.
> + ///
> + /// # Safety
> + ///
> + /// The caller must ensure that the work item's destructor runs before any
> + /// lifetime it captures expires (i.e., the work item must not be forgotten).

It seems like this requirement is due to cancel_work_sync(). But what happens
if the item is enqueued with enqueue_scoped() on two work queues
simultaneously? Would cancel_work_sync() wait for both queues?

Docs seem to warn against it, IIUC?

"Cancel work and wait for its execution to finish. This function can be used
even if the work re-queues itself or migrates to another workqueue. On return
from this function, work is guaranteed to be not pending or executing on any
CPU —> as long as there aren’t racing enqueues. <—"

> + #[inline]
> + pub unsafe fn enqueue_scoped<W, const ID: u64>(&self, w: W) -> W::EnqueueOutput
> + where
> + W: RawWorkItem<ID> + Send,
> {