[PATCH v4 0/2] Add new workqueue wrapper and enqueue on cpu functions

[PATCH v4 0/2] Add new workqueue wrapper and enqueue on cpu functions

[Marco Crivellari]

Hi,

Recently the workqueue code has been changed introducing two new workqueue,
system_percpu_wq and system_dfl_wq, as a future replacement for system_wq and
system_unbound_wq respectively.

The change has been introduced by:
    'commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")'

The old workqueue(s) will be removed in a next release cycle.

=== Introduced Changes by this series ===

1) [P 1] Add wrapper for the new system_dfl_wq
  -   This change introduce two new Rust functions in order to add a wrapper for
      the new wq(s) defined in the C code.

2) [P 2] Add wrapper for system_percpu_wq and two new functions
  -   The new functions added are enqueue_cpu() and enqueue_delayed_cpu() and
      are accepting a u32 parameter, the id of the CPU on which the work should
      be scheduled on.


Thanks!

---
Changes in v4:
- two new function added in the Queue implementation:
  * enqueue_cpu()
  * enqueue_delayed_cpu()

  These functions receive a u32 CPU id in order to schedule work on that CPU.

  More info can be found in the v3 discussion:
  https://lore.kernel.org/all/CAAofZF6jcCAdDjRp-7w7+_ZgOG4k3apxbSiKvGoUDVf5hw0GhA@mail.gmail.com/

Changes in v3:
- added a proper comment documenting the new added functions.

Changes in v2:
- added system_percpu() and system_dfl() in order to use the new
  wq defined in the C code.

- fixed misleading paragraph in the commit log (no warnings are currently
  present).

Marco Crivellari (2):
  rust: add system_dfl() around the new system_dfl_wq
  rust: add system_percpu() and per-cpu enqueue functions

 rust/kernel/sync/completion.rs |   2 +-
 rust/kernel/workqueue.rs       | 110 +++++++++++++++++++++++++++++++--
 2 files changed, 105 insertions(+), 7 deletions(-)

-- 
2.52.0

[PATCH v4 1/2] rust: add system_dfl() around the new system_dfl_wq

[Marco Crivellari]

The C code defines 2 new workqueues: system_percpu_wq and system_dfl_wq,
respectively the futures replacement for system_wq and system_unbound_wq.

This change introduce system_dfl(), that use the new system_dfl_wq.

system_unbound_wq will be replaced in a future release cycle and should
not be used.

Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
---
 rust/kernel/workqueue.rs | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/rust/kernel/workqueue.rs b/rust/kernel/workqueue.rs
index 706e833e9702..300cc2bfe012 100644
--- a/rust/kernel/workqueue.rs
+++ b/rust/kernel/workqueue.rs
@@ -968,11 +968,25 @@ pub fn system_long() -> &'static Queue {
 /// Workers are not bound to any specific CPU, not concurrency managed, and all queued work items
 /// are executed immediately as long as `max_active` limit is not reached and resources are
 /// available.
+///
+/// Note: `system_unbound_wq` will be removed in a future release cycle. Use [`system_dfl_wq`] instead.
 pub fn system_unbound() -> &'static Queue {
     // SAFETY: `system_unbound_wq` is a C global, always available.
     unsafe { Queue::from_raw(bindings::system_unbound_wq) }
 }
 
+/// Returns the system unbound work queue (`system_dfl_wq`).
+///
+/// Workers are not bound to any specific CPU, not concurrency managed, and all queued work items
+/// are executed immediately as long as `max_active` limit is not reached and resources are
+/// available.
+///
+/// Note: `system_dfl_wq` will replace in a future release cycle [`system_unbound_wq`].
+pub fn system_dfl() -> &'static Queue {
+    // SAFETY: `system_dfl_wq` is a C global, always available.
+    unsafe { Queue::from_raw(bindings::system_dfl_wq) }
+}
+
 /// Returns the system freezable work queue (`system_freezable_wq`).
 ///
 /// It is equivalent to the one returned by [`system`] except that it's freezable.
-- 
2.52.0

[PATCH v4 2/2] rust: add system_percpu() and per-cpu enqueue functions

[Marco Crivellari]

The C code defines 2 new workqueues: system_percpu_wq and system_dfl_wq,
respectively the futures replacement for system_wq and system_unbound_wq.

This change introduce system_percpu(), that use the new system_percpu_wq.

In order to enqueue on a specific CPU, two new functions have been added
to the Queue implementation:

    enqueue_cpu()         - that receive a u32 CPU id as 2nd argument
    enqueue_delayed_cpu() - that receive a u32 CPU id as 3rd argument

system_wq (and so workqueue::system()) will be removed in a future
release cycle and should not be used.

Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
---
 rust/kernel/sync/completion.rs |  2 +-
 rust/kernel/workqueue.rs       | 96 +++++++++++++++++++++++++++++++---
 2 files changed, 91 insertions(+), 7 deletions(-)

diff --git a/rust/kernel/sync/completion.rs b/rust/kernel/sync/completion.rs
index c50012a940a3..ee6aa8f18507 100644
--- a/rust/kernel/sync/completion.rs
+++ b/rust/kernel/sync/completion.rs
@@ -38,7 +38,7 @@
 ///             done <- Completion::new(),
 ///         }), GFP_KERNEL)?;
 ///
-///         let _ = workqueue::system().enqueue(this.clone());
+///         let _ = workqueue::system_percpu().enqueue(this.clone());
 ///
 ///         Ok(this)
 ///     }
diff --git a/rust/kernel/workqueue.rs b/rust/kernel/workqueue.rs
index 300cc2bfe012..81a68d5062b7 100644
--- a/rust/kernel/workqueue.rs
+++ b/rust/kernel/workqueue.rs
@@ -67,7 +67,7 @@
 //! /// This method will enqueue the struct for execution on the system workqueue, where its value
 //! /// will be printed.
 //! fn print_later(val: Arc<MyStruct>) {
-//!     let _ = workqueue::system().enqueue(val);
+//!     let _ = workqueue::system_percpu().enqueue(val);
 //! }
 //! # print_later(MyStruct::new(42).unwrap());
 //! ```
@@ -121,11 +121,11 @@
 //! }
 //!
 //! fn print_1_later(val: Arc<MyStruct>) {
-//!     let _ = workqueue::system().enqueue::<Arc<MyStruct>, 1>(val);
+//!     let _ = workqueue::system_percpu().enqueue::<Arc<MyStruct>, 1>(val);
 //! }
 //!
 //! fn print_2_later(val: Arc<MyStruct>) {
-//!     let _ = workqueue::system().enqueue::<Arc<MyStruct>, 2>(val);
+//!     let _ = workqueue::system_percpu().enqueue::<Arc<MyStruct>, 2>(val);
 //! }
 //! # print_1_later(MyStruct::new(24, 25).unwrap());
 //! # print_2_later(MyStruct::new(41, 42).unwrap());
@@ -171,13 +171,13 @@
 //! /// This method will enqueue the struct for execution on the system workqueue, where its value
 //! /// will be printed 12 jiffies later.
 //! fn print_later(val: Arc<MyStruct>) {
-//!     let _ = workqueue::system().enqueue_delayed(val, 12);
+//!     let _ = workqueue::system_percpu().enqueue_delayed(val, 12);
 //! }
 //!
 //! /// It is also possible to use the ordinary `enqueue` method together with `DelayedWork`. This
 //! /// is equivalent to calling `enqueue_delayed` with a delay of zero.
 //! fn print_now(val: Arc<MyStruct>) {
-//!     let _ = workqueue::system().enqueue(val);
+//!     let _ = workqueue::system_percpu().enqueue(val);
 //! }
 //! # print_later(MyStruct::new(42).unwrap());
 //! # print_now(MyStruct::new(42).unwrap());
@@ -292,6 +292,39 @@ pub fn enqueue<W, const ID: u64>(&self, w: W) -> W::EnqueueOutput
         }
     }
 
+    /// Enqueues a work item on a specific CPU.
+    ///
+    /// This may fail if the work item is already enqueued in a workqueue.
+    ///
+    /// The work item will be submitted on cpu_id.
+    pub fn enqueue_cpu<W, const ID: u64>(&self, w: W, cpu_id: u32) -> W::EnqueueOutput
+    where
+        W: RawWorkItem<ID> + Send + 'static,
+    {
+        let queue_ptr = self.0.get();
+
+        // SAFETY: We only return `false` if the `work_struct` is already in a workqueue. The other
+        // `__enqueue` requirements are not relevant since `W` is `Send` and static.
+        //
+        // The call to `bindings::queue_work_on` will dereference the provided raw pointer, which
+        // is ok because `__enqueue` guarantees that the pointer is valid for the duration of this
+        // closure.
+        //
+        // Furthermore, if the C workqueue code accesses the pointer after this call to
+        // `__enqueue`, then the work item was successfully enqueued, and `bindings::queue_work_on`
+        // will have returned true. In this case, `__enqueue` promises that the raw pointer will
+        // stay valid until we call the function pointer in the `work_struct`, so the access is ok.
+        unsafe {
+            w.__enqueue(move |work_ptr| {
+                bindings::queue_work_on(
+                    cpu_id as ffi::c_int,
+                    queue_ptr,
+                    work_ptr,
+                )
+            })
+        }
+    }
+
     /// Enqueues a delayed work item.
     ///
     /// This may fail if the work item is already enqueued in a workqueue.
@@ -328,6 +361,42 @@ pub fn enqueue_delayed<W, const ID: u64>(&self, w: W, delay: Jiffies) -> W::Enqu
         }
     }
 
+    /// Enqueues a delayed work item on a specific CPU.
+    ///
+    /// This may fail if the work item is already enqueued in a workqueue.
+    ///
+    /// The work item will be submitted on cpu_id.
+    pub fn enqueue_delayed_cpu<W, const ID: u64>(&self, w: W, delay: Jiffies, cpu_id: u32) -> W::EnqueueOutput
+    where
+        W: RawDelayedWorkItem<ID> + Send + 'static,
+    {
+        let queue_ptr = self.0.get();
+
+        // SAFETY: We only return `false` if the `work_struct` is already in a workqueue. The other
+        // `__enqueue` requirements are not relevant since `W` is `Send` and static.
+        //
+        // The call to `bindings::queue_delayed_work_on` will dereference the provided raw pointer,
+        // which is ok because `__enqueue` guarantees that the pointer is valid for the duration of
+        // this closure, and the safety requirements of `RawDelayedWorkItem` expands this
+        // requirement to apply to the entire `delayed_work`.
+        //
+        // Furthermore, if the C workqueue code accesses the pointer after this call to
+        // `__enqueue`, then the work item was successfully enqueued, and
+        // `bindings::queue_delayed_work_on` will have returned true. In this case, `__enqueue`
+        // promises that the raw pointer will stay valid until we call the function pointer in the
+        // `work_struct`, so the access is ok.
+        unsafe {
+            w.__enqueue(move |work_ptr| {
+                bindings::queue_delayed_work_on(
+                    cpu_id as ffi::c_int,
+                    queue_ptr,
+                    container_of!(work_ptr, bindings::delayed_work, work),
+                    delay,
+                )
+            })
+        }
+    }
+
     /// Tries to spawn the given function or closure as a work item.
     ///
     /// This method can fail because it allocates memory to store the work item.
@@ -934,17 +1003,32 @@ unsafe impl<T, const ID: u64> RawDelayedWorkItem<ID> for Pin<KBox<T>>
 {
 }
 
-/// Returns the system work queue (`system_wq`).
+/// Returns the per-cpu system work queue (`system_wq`).
 ///
 /// It is the one used by `schedule[_delayed]_work[_on]()`. Multi-CPU multi-threaded. There are
 /// users which expect relatively short queue flush time.
 ///
 /// Callers shouldn't queue work items which can run for too long.
+///
+/// Note: `system_wq` will be removed in a future release cycle. Use [`system_percpu_wq`] instead.
 pub fn system() -> &'static Queue {
     // SAFETY: `system_wq` is a C global, always available.
     unsafe { Queue::from_raw(bindings::system_wq) }
 }
 
+/// Returns the per-cpu system work queue (`system_percpu_wq`).
+///
+/// It is the one used by `schedule[_delayed]_work[_on]()`. Multi-CPU multi-threaded. There are
+/// users which expect relatively short queue flush time.
+///
+/// Callers shouldn't queue work items which can run for too long.
+///
+/// Note: `system_percpu_wq` will replace `system_wq` in a future release cycle.
+pub fn system_percpu() -> &'static Queue {
+    // SAFETY: `system_percpu_wq` is a C global, always available.
+    unsafe { Queue::from_raw(bindings::system_percpu_wq) }
+}
+
 /// Returns the system high-priority work queue (`system_highpri_wq`).
 ///
 /// It is similar to the one returned by [`system`] but for work items which require higher
-- 
2.52.0

Re: [PATCH v4 2/2] rust: add system_percpu() and per-cpu enqueue functions

[Alice Ryhl]

On Tue, Feb 03, 2026 at 04:28:17PM +0100, Marco Crivellari wrote:
> The C code defines 2 new workqueues: system_percpu_wq and system_dfl_wq,
> respectively the futures replacement for system_wq and system_unbound_wq.
> 
> This change introduce system_percpu(), that use the new system_percpu_wq.
> 
> In order to enqueue on a specific CPU, two new functions have been added
> to the Queue implementation:
> 
>     enqueue_cpu()         - that receive a u32 CPU id as 2nd argument
>     enqueue_delayed_cpu() - that receive a u32 CPU id as 3rd argument
> 
> system_wq (and so workqueue::system()) will be removed in a future
> release cycle and should not be used.
> 
> Suggested-by: Tejun Heo <tj@kernel.org>
> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>

Reviewed-by: Alice Ryhl <aliceryhl@google.com>

Re: [PATCH v4 1/2] rust: add system_dfl() around the new system_dfl_wq

[Alice Ryhl]

On Tue, Feb 03, 2026 at 04:28:16PM +0100, Marco Crivellari wrote:
> The C code defines 2 new workqueues: system_percpu_wq and system_dfl_wq,
> respectively the futures replacement for system_wq and system_unbound_wq.
> 
> This change introduce system_dfl(), that use the new system_dfl_wq.
> 
> system_unbound_wq will be replaced in a future release cycle and should
> not be used.
> 
> Suggested-by: Tejun Heo <tj@kernel.org>
> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>

Reviewed-by: Alice Ryhl <aliceryhl@google.com>

Re: [PATCH v4 1/2] rust: add system_dfl() around the new system_dfl_wq

[Gary Guo]

On Tue Feb 3, 2026 at 3:28 PM GMT, Marco Crivellari wrote:
> The C code defines 2 new workqueues: system_percpu_wq and system_dfl_wq,
> respectively the futures replacement for system_wq and system_unbound_wq.
>
> This change introduce system_dfl(), that use the new system_dfl_wq.
>
> system_unbound_wq will be replaced in a future release cycle and should
> not be used.
>
> Suggested-by: Tejun Heo <tj@kernel.org>
> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
> ---
>  rust/kernel/workqueue.rs | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
>
> diff --git a/rust/kernel/workqueue.rs b/rust/kernel/workqueue.rs
> index 706e833e9702..300cc2bfe012 100644
> --- a/rust/kernel/workqueue.rs
> +++ b/rust/kernel/workqueue.rs
> @@ -968,11 +968,25 @@ pub fn system_long() -> &'static Queue {
>  /// Workers are not bound to any specific CPU, not concurrency managed, and all queued work items
>  /// are executed immediately as long as `max_active` limit is not reached and resources are
>  /// available.
> +///
> +/// Note: `system_unbound_wq` will be removed in a future release cycle. Use [`system_dfl_wq`] instead.
>  pub fn system_unbound() -> &'static Queue {
>      // SAFETY: `system_unbound_wq` is a C global, always available.
>      unsafe { Queue::from_raw(bindings::system_unbound_wq) }
>  }

Hi Marco,

The Rust change looks good to me.

Reviewed-by: Gary Guo <gary@garyguo.net>

Is there any reason that we cannot migrate the user early by just returning
`system_dfl_wq` inside `system_unbound`? (I guess the question also applies on
why system_unbound_wq cannot be the same pointer as system_dfl_wq).

Also, I feel that `dfl` is not a very intuitive name. I searched the list and
the commit history for a while and cannot find the exact explaination on what it
means? Does it mean "default" or something else?

Best,
Gary

>  
> +/// Returns the system unbound work queue (`system_dfl_wq`).
> +///
> +/// Workers are not bound to any specific CPU, not concurrency managed, and all queued work items
> +/// are executed immediately as long as `max_active` limit is not reached and resources are
> +/// available.
> +///
> +/// Note: `system_dfl_wq` will replace in a future release cycle [`system_unbound_wq`].
> +pub fn system_dfl() -> &'static Queue {
> +    // SAFETY: `system_dfl_wq` is a C global, always available.
> +    unsafe { Queue::from_raw(bindings::system_dfl_wq) }
> +}
> +
>  /// Returns the system freezable work queue (`system_freezable_wq`).
>  ///
>  /// It is equivalent to the one returned by [`system`] except that it's freezable.

Re: [PATCH v4 1/2] rust: add system_dfl() around the new system_dfl_wq

[kernel test robot]

Hi Marco,

kernel test robot noticed the following build warnings:

[auto build test WARNING on rust/rust-next]
[also build test WARNING on linus/master v6.19-rc8 next-20260203]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Marco-Crivellari/rust-add-system_dfl-around-the-new-system_dfl_wq/20260203-233415
base:   https://github.com/Rust-for-Linux/linux rust-next
patch link:    https://lore.kernel.org/r/20260203152818.317806-2-marco.crivellari%40suse.com
patch subject: [PATCH v4 1/2] rust: add system_dfl() around the new system_dfl_wq
config: x86_64-rhel-9.4-rust (https://download.01.org/0day-ci/archive/20260204/202602040119.xqN5Fe8s-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260204/202602040119.xqN5Fe8s-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602040119.xqN5Fe8s-lkp@intel.com/

All warnings (new ones prefixed by >>):

>> warning: unresolved link to `system_dfl_wq`
   --> rust/kernel/workqueue.rs:972:80
   |
   972 | /// Note: `system_unbound_wq` will be removed in a future release cycle. Use [`system_dfl_wq`] instead.
   |                                                                                ^^^^^^^^^^^^^ no item named `system_dfl_wq` in scope
   |
   = help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`
   = note: `#[warn(rustdoc::broken_intra_doc_links)]` on by default
--
>> warning: unresolved link to `system_unbound_wq`
   --> rust/kernel/workqueue.rs:984:68
   |
   984 | /// Note: `system_dfl_wq` will replace in a future release cycle [`system_unbound_wq`].
   |                                                                    ^^^^^^^^^^^^^^^^^ no item named `system_unbound_wq` in scope
   |
   = help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v4 2/2] rust: add system_percpu() and per-cpu enqueue functions

[kernel test robot]

Hi Marco,

kernel test robot noticed the following build errors:

[auto build test ERROR on rust/rust-next]
[also build test ERROR on linus/master v6.19-rc8 next-20260203]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Marco-Crivellari/rust-add-system_dfl-around-the-new-system_dfl_wq/20260203-233415
base:   https://github.com/Rust-for-Linux/linux rust-next
patch link:    https://lore.kernel.org/r/20260203152818.317806-3-marco.crivellari%40suse.com
patch subject: [PATCH v4 2/2] rust: add system_percpu() and per-cpu enqueue functions
config: x86_64-rhel-9.4-rust (https://download.01.org/0day-ci/archive/20260204/202602040208.hNcu9QEl-lkp@intel.com/config)
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
rustc: rustc 1.88.0 (6b00bc388 2025-06-23)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260204/202602040208.hNcu9QEl-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202602040208.hNcu9QEl-lkp@intel.com/

All error/warnings (new ones prefixed by >>):

   PATH=/opt/cross/clang-20/bin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
   INFO PATH=/opt/cross/rustc-1.88.0-bindgen-0.72.1/cargo/bin:/opt/cross/clang-20/bin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
   /usr/bin/timeout -k 100 12h /usr/bin/make KCFLAGS= -fno-crash-diagnostics -Wno-error=return-type -Wreturn-type -funsigned-char -Wundef -falign-functions=64 W=1 --keep-going LLVM=1 -j32 -C source O=/kbuild/obj/consumer/x86_64-rhel-9.4-rust ARCH=x86_64 SHELL=/bin/bash rustfmtcheck
   make: Entering directory '/kbuild/src/consumer'
   make[1]: Entering directory '/kbuild/obj/consumer/x86_64-rhel-9.4-rust'
>> Diff in rust/kernel/workqueue.rs:316:
            // stay valid until we call the function pointer in the `work_struct`, so the access is ok.
            unsafe {
                w.__enqueue(move |work_ptr| {
   -                bindings::queue_work_on(
   -                    cpu_id as ffi::c_int,
   -                    queue_ptr,
   -                    work_ptr,
   -                )
   +                bindings::queue_work_on(cpu_id as ffi::c_int, queue_ptr, work_ptr)
                })
            }
        }
   Diff in rust/kernel/workqueue.rs:366:
        /// This may fail if the work item is already enqueued in a workqueue.
        ///
        /// The work item will be submitted on cpu_id.
   -    pub fn enqueue_delayed_cpu<W, const ID: u64>(&self, w: W, delay: Jiffies, cpu_id: u32) -> W::EnqueueOutput
   +    pub fn enqueue_delayed_cpu<W, const ID: u64>(
   +        &self,
   +        w: W,
   +        delay: Jiffies,
   +        cpu_id: u32,
   +    ) -> W::EnqueueOutput
        where
            W: RawDelayedWorkItem<ID> + Send + 'static,
        {
>> Diff in rust/kernel/workqueue.rs:316:
            // stay valid until we call the function pointer in the `work_struct`, so the access is ok.
            unsafe {
                w.__enqueue(move |work_ptr| {
   -                bindings::queue_work_on(
   -                    cpu_id as ffi::c_int,
   -                    queue_ptr,
   -                    work_ptr,
   -                )
   +                bindings::queue_work_on(cpu_id as ffi::c_int, queue_ptr, work_ptr)
                })
            }
        }
   Diff in rust/kernel/workqueue.rs:366:
        /// This may fail if the work item is already enqueued in a workqueue.
        ///
        /// The work item will be submitted on cpu_id.
   -    pub fn enqueue_delayed_cpu<W, const ID: u64>(&self, w: W, delay: Jiffies, cpu_id: u32) -> W::EnqueueOutput
   +    pub fn enqueue_delayed_cpu<W, const ID: u64>(
   +        &self,
   +        w: W,
   +        delay: Jiffies,
   +        cpu_id: u32,
   +    ) -> W::EnqueueOutput
        where
            W: RawDelayedWorkItem<ID> + Send + 'static,
        {
   make[2]: *** [Makefile:1871: rustfmt] Error 123
   make[2]: Target 'rustfmtcheck' not remade because of errors.
   make[1]: Leaving directory '/kbuild/obj/consumer/x86_64-rhel-9.4-rust'
   make[1]: *** [Makefile:248: __sub-make] Error 2
   make[1]: Target 'rustfmtcheck' not remade because of errors.
   make: *** [Makefile:248: __sub-make] Error 2
   make: Target 'rustfmtcheck' not remade because of errors.
   make: Leaving directory '/kbuild/src/consumer'
--
>> warning: unresolved link to `system_percpu_wq`
   --> rust/kernel/workqueue.rs:1013:72
   |
   1013 | /// Note: `system_wq` will be removed in a future release cycle. Use [`system_percpu_wq`] instead.
   |                                                                        ^^^^^^^^^^^^^^^^ no item named `system_percpu_wq` in scope
   |
   = help: to escape `[` and `]` characters, add '\' before them like `\[` or `\]`
   = note: `#[warn(rustdoc::broken_intra_doc_links)]` on by default

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH v4 1/2] rust: add system_dfl() around the new system_dfl_wq

[Marco Crivellari]

On Tue, Feb 3, 2026 at 4:53 PM Gary Guo <gary@garyguo.net> wrote:
> Hi Marco,
>
> The Rust change looks good to me.
>
> Reviewed-by: Gary Guo <gary@garyguo.net>

Hi Gary,

Thanks!

> Is there any reason that we cannot migrate the user early by just returning
> `system_dfl_wq` inside `system_unbound`? (I guess the question also applies on
> why system_unbound_wq cannot be the same pointer as system_dfl_wq).

The 1st version was like you mentioned, both for system() and system_unbound().
It's one of the request made by Alice:

https://lore.kernel.org/all/aL1lkN5WcWkwiq3S@google.com/

To me it was ok to change with her suggestion. :-)

> Also, I feel that `dfl` is not a very intuitive name. I searched the list and
> the commit history for a while and cannot find the exact explaination on what it
> means? Does it mean "default" or something else?

Yes, "dfl" means "default".

There is a huge Workqueue API refactoring. We also noticed many subsystem
used system_wq (the - now - old per-cpu workqueue) but many of them didn't
really benefit from per-cpu work.

So the idea was, at first, to refactor of the workqueue name changing system_wq
to system_percpu_wq and system_unbound_wq to system_dfl_wq, to make
clear this should be the default choice.

If you want other details check this discussion:

https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/

Thank you!

-- 

Marco Crivellari

L3 Support Engineer

Re: [PATCH v4 1/2] rust: add system_dfl() around the new system_dfl_wq

[Alice Ryhl]

On Tue, Feb 03, 2026 at 03:53:39PM +0000, Gary Guo wrote:
> Is there any reason that we cannot migrate the user early by just returning
> `system_dfl_wq` inside `system_unbound`? (I guess the question also applies on
> why system_unbound_wq cannot be the same pointer as system_dfl_wq).

I think this is confusing. Let's just rename it here and update the
callers. Otherwise Rust gets out of sync with C naming-wise.

> Also, I feel that `dfl` is not a very intuitive name. I searched the list and
> the commit history for a while and cannot find the exact explaination on what it
> means? Does it mean "default" or something else?

This I agree with. dfl is not a good name. Let's at least call it
"default" or "unbound" or whatever.

Alice

Re: [PATCH v4 1/2] rust: add system_dfl() around the new system_dfl_wq

[Marco Crivellari]

On Wed, Feb 4, 2026 at 11:52 AM Alice Ryhl <aliceryhl@google.com> wrote:
>
> On Tue, Feb 03, 2026 at 03:53:39PM +0000, Gary Guo wrote:
> > Is there any reason that we cannot migrate the user early by just returning
> > `system_dfl_wq` inside `system_unbound`? (I guess the question also applies on
> > why system_unbound_wq cannot be the same pointer as system_dfl_wq).
>
> I think this is confusing. Let's just rename it here and update the
> callers. Otherwise Rust gets out of sync with C naming-wise.
>
> > Also, I feel that `dfl` is not a very intuitive name. I searched the list and
> > the commit history for a while and cannot find the exact explaination on what it
> > means? Does it mean "default" or something else?
>
> This I agree with. dfl is not a good name. Let's at least call it
> "default" or "unbound" or whatever.

Ok, I will rename system_dfl() to system_default() (to keep consistent
the name with C).

Thanks!

-- 

Marco Crivellari

L3 Support Engineer

Re: [PATCH v4 1/2] rust: add system_dfl() around the new system_dfl_wq

[Gary Guo]

On Wed Feb 4, 2026 at 9:43 AM GMT, Marco Crivellari wrote:
> On Tue, Feb 3, 2026 at 4:53 PM Gary Guo <gary@garyguo.net> wrote:
>> Hi Marco,
>>
>> The Rust change looks good to me.
>>
>> Reviewed-by: Gary Guo <gary@garyguo.net>
>
> Hi Gary,
>
> Thanks!
>
>> Is there any reason that we cannot migrate the user early by just returning
>> `system_dfl_wq` inside `system_unbound`? (I guess the question also applies on
>> why system_unbound_wq cannot be the same pointer as system_dfl_wq).
>
> The 1st version was like you mentioned, both for system() and system_unbound().
> It's one of the request made by Alice:
>
> https://lore.kernel.org/all/aL1lkN5WcWkwiq3S@google.com/
>
> To me it was ok to change with her suggestion. :-)
>
>> Also, I feel that `dfl` is not a very intuitive name. I searched the list and
>> the commit history for a while and cannot find the exact explaination on what it
>> means? Does it mean "default" or something else?
>
> Yes, "dfl" means "default".
>
> There is a huge Workqueue API refactoring. We also noticed many subsystem
> used system_wq (the - now - old per-cpu workqueue) but many of them didn't
> really benefit from per-cpu work.

Yeah, I appreciate the system -> system_percpu renaming which does make it clear
that this is percpu. However I think `system_unbound_wq` to `system_dfl_wq` is
somewhat less clear?

What is a problem to leave this still being `system_unbound`? User would need to
make a choice, and unless they know they want `percpu` it feels like natural
that they're going to use the unbounded option.

Best,
Gary

>
> So the idea was, at first, to refactor of the workqueue name changing system_wq
> to system_percpu_wq and system_unbound_wq to system_dfl_wq, to make
> clear this should be the default choice.
>
> If you want other details check this discussion:
>
> https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/
>
> Thank you!

Re: [PATCH v4 1/2] rust: add system_dfl() around the new system_dfl_wq

[Marco Crivellari]

On Wed, Feb 4, 2026 at 5:50 PM Gary Guo <gary@garyguo.net> wrote:
> [...]
> Yeah, I appreciate the system -> system_percpu renaming which does make it clear
> that this is percpu. However I think `system_unbound_wq` to `system_dfl_wq` is
> somewhat less clear?
>
> What is a problem to leave this still being `system_unbound`? User would need to
> make a choice, and unless they know they want `percpu` it feels like natural
> that they're going to use the unbounded option.
>

Hi Gary,

Yes, it feels natural, as you said. But there are cases where
system_wq has been used,
maybe because the name felt like a "default system workqueue", or for
other reasons.

There are currently some places where we have already converted from
system_wq to
system_dfl_wq, because they don't need to be per-cpu. So I think that
suggesting the
use of an unbound workqueue as default it could work better. :-)
Then whoever really needs to be per-cpu, would use the system_percpu_wq.

BTW, few examples about the mentioned conversions:

"ASoC: SDCA: Replace use of system_wq with system_dfl_wq"
https://lore.kernel.org/all/20251230143429.179643-1-marco.crivellari@suse.com/

"Input: gpio_keys - replace use of system_wq with system_dfl_wq"
https://lore.kernel.org/all/20251106141955.218911-2-marco.crivellari@suse.com/

"regulator: irq_helper: replace use of system_wq with system_dfl_wq"
https://lore.kernel.org/all/20250929155053.400342-2-marco.crivellari@suse.com/

"regulator: qcomm-labibb: replace use of system_wq with system_dfl_wq"
https://lore.kernel.org/all/20251106145003.245866-1-marco.crivellari@suse.com/

We're going to have more changes like the above.

Also noticed that system_unbound_wq has been already renamed to system_dfl_wq
in about ~120 places in the code. :-)

Thanks!


--

Marco Crivellari

L3 Support Engineer