linux-kernel - Re: [PATCH v2 2/4] Workqueue: add system_dfl

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

Message-ID: <aEinW8EpI2x6JrnO@slm.duckdns.org>
Date: Tue, 10 Jun 2025 11:44:59 -1000
From: Tejun Heo <tj@...nel.org>
To: Marco Crivellari <marco.crivellari@...e.com>
Cc: Lai Jiangshan <jiangshanlai@...il.com>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Frederic Weisbecker <frederic@...nel.org>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Michal Hocko <mhocko@...e.com>
Subject: Re: [PATCH v2 2/4] Workqueue: add system_dfl_wq

Hello,

On Tue, Jun 10, 2025 at 10:56:13AM +0200, Marco Crivellari wrote:
> >What is the reason for removing system_unbound_wq? I believe system_unbound_wq
> >is a perfectly appropriate and descriptive name for its callers. I’m not opposed
> >to system_dfl_wq as long as it will be an alias for system_unbound_wq (or even
> >system_percpu_wq, if that can be configured at boot time by sysadim).
> 
> The rename to system_dfl_wq is mostly to make sure this is the default wq choice
> when per-cpu is not strictly needed.
> It has been proposed here, anyhow:
> 
> https://lore.kernel.org/all/Z79E_gbWm9j9bkfR@slm.duckdns.org/

I think we ultimately want to converge on one thing and I think it does make
sense to make one behavior default over the other. ie. If we make percpu the
flavor that requires explicit designation, unbound by default becomes the
default. ie. I don't want a situation where there are system_percpu_wq and
system_unbound_wq as it's not clear which one is preferred, and if we add
system_dfl_wq to clarify the situation, at least in the long term, having
another alias for it makes things unnecessarily confusing.

So, if we're flipping the default, I'd rather remove the unbound name from
the interface. We can keep using unbound inside workqueue implementation of
course.

Thanks.

-- 
tejun