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.0Hi 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
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.
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
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
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
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!
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>
© 2016 - 2026 Red Hat, Inc.