When a workqueue is shut down, delayed work that is pending but not
scheduled does not get properly cleaned up, so it's not safe to use
`enqueue_delayed` on a workqueue that might be destroyed. To fix this,
restricted `enqueue_delayed` to static queues.

Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
 rust/kernel/workqueue.rs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rust/kernel/workqueue.rs b/rust/kernel/workqueue.rs
index 706e833e9702ba4ba9aa7756b0e1fa80079a63fc..901102a8bca54c9fb58655d80fc9624b4dfe1dc1 100644
--- a/rust/kernel/workqueue.rs
+++ b/rust/kernel/workqueue.rs
@@ -297,7 +297,7 @@ pub fn enqueue<W, const ID: u64>(&self, w: W) -> W::EnqueueOutput
     /// This may fail if the work item is already enqueued in a workqueue.
     ///
     /// The work item will be submitted using `WORK_CPU_UNBOUND`.
-    pub fn enqueue_delayed<W, const ID: u64>(&self, w: W, delay: Jiffies) -> W::EnqueueOutput
+    pub fn enqueue_delayed<W, const ID: u64>(&'static self, w: W, delay: Jiffies) -> W::EnqueueOutput
     where
         W: RawDelayedWorkItem<ID> + Send + 'static,
     {

-- 
2.51.2.1041.gc1ab5b90ca-goog

On 11/13/25 2:01 AM, Alice Ryhl wrote:
> When a workqueue is shut down, delayed work that is pending but not
> scheduled does not get properly cleaned up, so it's not safe to use
> `enqueue_delayed` on a workqueue that might be destroyed. To fix this,
> restricted `enqueue_delayed` to static queues.
> 
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
>  rust/kernel/workqueue.rs | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/rust/kernel/workqueue.rs b/rust/kernel/workqueue.rs
> index 706e833e9702ba4ba9aa7756b0e1fa80079a63fc..901102a8bca54c9fb58655d80fc9624b4dfe1dc1 100644
> --- a/rust/kernel/workqueue.rs
> +++ b/rust/kernel/workqueue.rs
> @@ -297,7 +297,7 @@ pub fn enqueue<W, const ID: u64>(&self, w: W) -> W::EnqueueOutput
>      /// This may fail if the work item is already enqueued in a workqueue.
>      ///
>      /// The work item will be submitted using `WORK_CPU_UNBOUND`.
> -    pub fn enqueue_delayed<W, const ID: u64>(&self, w: W, delay: Jiffies) -> W::EnqueueOutput
> +    pub fn enqueue_delayed<W, const ID: u64>(&'static self, w: W, delay: Jiffies) -> W::EnqueueOutput

Hi Alice,

Looks good, just a documentation suggestion below.

Reviewed-by: John Hubbard <jhubbard@nvidia.com>


I think it deserves a documentation comment (even though patch 2/2
has not yet arrived, we can still document this accurately), for example:

diff --git a/rust/kernel/workqueue.rs b/rust/kernel/workqueue.rs
index 313d897fe93c..9e55d68f3b0d 100644
--- a/rust/kernel/workqueue.rs
+++ b/rust/kernel/workqueue.rs
@@ -299,6 +299,8 @@ pub fn enqueue<W, const ID: u64>(&self, w: W) -> W::EnqueueOutput
     /// Enqueues a delayed work item.
     ///
     /// This may fail if the work item is already enqueued in a workqueue.
+    /// This is only valid for global workqueues (with static lifetimes) because those are the only
+    /// ones that outlive all possible delayed work items.
     ///
     /// The work item will be submitted using `WORK_CPU_UNBOUND`.
     pub fn enqueue_delayed<W, const ID: u64>(&'static self, w: W, delay: Jiffies) -> W::EnqueueOutput


Also, rustfmt (1.8.0-stable) split the changed line for me, upon
saving the file, I'm not sure if it will do that for everyone. Just
a heads up.


thanks,
-- 
John Hubbard

On Thu, Nov 13, 2025 at 9:40 PM John Hubbard <jhubbard@nvidia.com> wrote:
>
> Also, rustfmt (1.8.0-stable) split the changed line for me, upon
> saving the file, I'm not sure if it will do that for everyone. Just
> a heads up.

If `rustfmt` happens to behave differently for different people (in
the Rust versions we support), then that is a (quite painful) bug for
us, so please let me know!

Cheers,
Miguel

On Thu, Nov 13, 2025 at 11:01 AM Alice Ryhl <aliceryhl@google.com> wrote:
>
> When a workqueue is shut down, delayed work that is pending but not
> scheduled does not get properly cleaned up, so it's not safe to use
> `enqueue_delayed` on a workqueue that might be destroyed. To fix this,
> restricted `enqueue_delayed` to static queues.

Should this have a Fixes and Cc: stable?

Cheers,
Miguel

On Thu, Nov 13, 2025 at 11:06 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Thu, Nov 13, 2025 at 11:01 AM Alice Ryhl <aliceryhl@google.com> wrote:
> >
> > When a workqueue is shut down, delayed work that is pending but not
> > scheduled does not get properly cleaned up, so it's not safe to use
> > `enqueue_delayed` on a workqueue that might be destroyed. To fix this,
> > restricted `enqueue_delayed` to static queues.
>
> Should this have a Fixes and Cc: stable?

I could go either way. Without the next patch, there's no way to use a
non-global workqueue. But probably is useful to backport anyway and
there's certainly no harm.

Alice

On Thu, Nov 13, 2025 at 11:08 AM Alice Ryhl <aliceryhl@google.com> wrote:
>
> I could go either way. Without the next patch, there's no way to use a
> non-global workqueue. But probably is useful to backport anyway and
> there's certainly no harm.

Yeah, I would say then let's propose it for stable to be safe than
sorry in case this gets missed later on (or someone else out there
uses only the other one etc.).

Cc: stable@vger.kernel.org
Fixes: 7c098cd5eaae ("workqueue: rust: add delayed work items")

Thanks!

Cheers,
Miguel