linux-kernel - Re: [PATCH 0/4] Workqueue: rename system workqueue and add WQ

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aBlMLQl504ThYbnf@slm.duckdns.org>
Date: Mon, 5 May 2025 13:39:25 -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>
Subject: Re: [PATCH 0/4] Workqueue: rename system workqueue and add WQ_PERCPU

Hello,

On Sat, May 03, 2025 at 10:28:30AM +0200, Marco Crivellari wrote:
> Hi!
> 
> This series is the follow up of the discussion from:
> 	"workqueue: Always use wq_select_unbound_cpu() for WORK_CPU_UNBOUND."
> 	https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/

Can you please make a summary of the discussion here? Referring to old
thread is useful but it'd be nice to have the rationales laid out in the
patchset - why this is desirable, what is the transition plan and what are
the rationales for it? Also, please include a short summary in the patches.

> 1)  [P 1-2] system workqueue rename:
>  
> 	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.
> 	
> 	system_wq renamed in system_percpu_wq, while system_unbound_wq
> 	became system_dfl_wq.

Let's keep the old names for a release or two and trigger printk_once()
warnings about the renames. These are pretty widely used, so I think it
warrants a bit of extra effort.

> 2)  [P 3] Introduction of WQ_PERCPU.
> 
> 	This patch adds a new WQ_PERCPU flag to explicitly request the legacy
> 	per-CPU behavior. WQ_UNBOUND will be removed once the migration is
> 	complete.

I wouldn't call per-cpu behavior legacy. There are plenty of cases that need
per-cpu behavior for correctness and/or performance.

> 	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.

Similarly, let's warn about violations and assume the old behavior at first.

> 3)  [P 4] alloc_workqueue() callee should pass explicitly WQ_PERCPU.

Do you mean caller?

> 
> 	This patch ensures that every caller that needs per-cpu workqueue
> 	will explicitly require it, using the WQ_PERCPU flag.

How is 3) different from 2)?

Thanks.

-- 
tejun