lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAofZF5pqsGvnCS5HbmQKT8b_ydEnycv2fWF=wbFkSgu+ds2gA@mail.gmail.com>
Date: Wed, 4 Feb 2026 10:43:51 +0100
From: Marco Crivellari <marco.crivellari@...e.com>
To: Gary Guo <gary@...yguo.net>
Cc: linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org, 
	Tejun Heo <tj@...nel.org>, Lai Jiangshan <jiangshanlai@...il.com>, 
	Frederic Weisbecker <frederic@...nel.org>, Sebastian Andrzej Siewior <bigeasy@...utronix.de>, 
	Michal Hocko <mhocko@...e.com>, Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	Alice Ryhl <aliceryhl@...gle.com>
Subject: Re: [PATCH v4 1/2] rust: add system_dfl() around the new system_dfl_wq

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ