linux-kernel - Re: [PATCH] platform/surface: acpi-notify: add WQ_PERCPU to 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAofZF52hxs_UbA+WkaugNceotzPMisziBj0+AKoL+X0pNrQbg@mail.gmail.com>
Date: Tue, 18 Nov 2025 14:27:57 +0100
From: Marco Crivellari <marco.crivellari@...e.com>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: LKML <linux-kernel@...r.kernel.org>, platform-driver-x86@...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>, Maximilian Luz <luzmaximilian@...il.com>, 
	Hans de Goede <hansg@...nel.org>
Subject: Re: [PATCH] platform/surface: acpi-notify: add WQ_PERCPU to
 alloc_workqueue users

Hi,

On Tue, Nov 18, 2025 at 12:30 PM Ilpo Järvinen
<ilpo.jarvinen@...ux.intel.com> wrote:
> [...]
> Hi,
>
> There's lots of words in this but it's extremely confusingly written.
>
> On one hand, you're saying "most workloads benefit from unbound queues"
> but then end up using percpu anyway in the actual diff!?!

Yes, to keep the same behavior.
There are subsystems who are asked to convert the workqueue to unbound.
So in this case I will send the v2 with the change.

> If this is to support refactoring efforts, start the
> description/justification in the changelog with that, with only a concise
> explanation of the refactoring goal (you don't need to explain everything
> that is already in the changelogs of the commits you refer above).

It makes sense.

> And I'd expect explanation to the forementioned inconsistency, it might be
> because of the refactoring in steps. But if that's the case, you should
> instead mention that either a) there will be a follow-up to migrate to
> unbound where applicable (assuming it cannot be done now) or b) state
> that this change is just to keep behavior the same and each case needs to
> be evaluated once the refactoring is complete whether unbound could be
> used or not.

What do you think, is it better in this way?

"
This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:

commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")

For more details see the Link tag below.

This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.

With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.

Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.

Suggested-by: Tejun Heo <tj@...nel.org>
Signed-off-by: Marco Crivellari <marco.crivellari@...e.com>
Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/
"

The Link is the original upstream discussion with all the details.
I think adding more details here will be too much (and unrelated with the
work itself).

> Also, there's one copy-pasted typo "worqueue" in the other patches
> relating to pdx86 (and likely all your other copy-pasted
> descriptions to other subsystems than pdx86 ;-)).

Uh, I completely missed that!

Thanks!
-- 

Marco Crivellari

L3 Support Engineer, Technology & Product