linux-kernel - Re: [PATCH 0/4] Workqueue: replace system wq and change alloc

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] [day] [month] [year] [list]

Message-ID: <aJ92vqBchsh-h-0z@slm.duckdns.org>
Date: Fri, 15 Aug 2025 08:04:46 -1000
From: Tejun Heo <tj@...nel.org>
To: Marco Crivellari <marco.crivellari@...e.com>
Cc: linux-kernel@...r.kernel.org, Lai Jiangshan <jiangshanlai@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Frederic Weisbecker <frederic@...nel.org>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Michal Hocko <mhocko@...e.com>
Subject: Re: [PATCH 0/4] Workqueue: replace system wq and change
 alloc_workqueue callers

Hello, Marco.

On Fri, Aug 15, 2025 at 11:45:06AM +0200, Marco Crivellari wrote:
> === Introduced Changes by this series ===
> 
> 1) [P 1-2] Replace use of system_wq and system_unbound_wq
> 
> 		system_wq is a per-CPU workqueue, but his name is not clear.
> 		system_unbound_wq is to be used when locality is not required.
> 		
> 		Because of that, system_wq has been renamed in system_percpu_wq, and
> 		system_unbound_wq has been renamed in system_dfl_wq.
> 
> 2) [P 3] add WQ_PERCPU to remaining alloc_workqueue() users 
> 
> 		Every alloc_workqueue() caller should use one among WQ_PERCPU or
> 		WQ_UNBOUND. This is actually enforced warning if both or none of them
> 		are present at the same time.
> 
> 		WQ_UNBOUND will be removed in a next release cycle.
> 		
> 3) [P 4] upgraded WQ_UNBOUND documentation
> 
> 		Added a note about the WQ_UNBOUND flag removal in a next release cycle.
> 		
> 		
> Per-subsystem changes will be submitted in different series inolving also
> maintainers.

I'm afraid these are a bit intrusive for me to apply directly. Can you
please split the patches in this and related serieses on subsystem tree
boundaries? e.g. Network flows through the same tree but different
filesystems often have their own trees. Please prefix the patch title with
the respective subsystem's name. As the base patch is already in the master
branch, you can ask each tree to take the patches. For trees that don't
respond after a couple pings, we can route them through wq tree.

Thanks.

-- 
tejun