linux-kernel - Re: [PATCH] crypto: qat - 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] [day] [month] [year] [list]

Message-ID: <CAAofZF4UJ1UGAH=r4cWn5HssTinY5e=aXRRMj95Bz40deakmjQ@mail.gmail.com>
Date: Wed, 12 Nov 2025 18:57:10 +0100
From: Marco Crivellari <marco.crivellari@...e.com>
To: Giovanni Cabiddu <giovanni.cabiddu@...el.com>
Cc: linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org, 
	qat-linux@...el.com, 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>, Herbert Xu <herbert@...dor.apana.org.au>, 
	"David S . Miller" <davem@...emloft.net>
Subject: Re: [PATCH] crypto: qat - add WQ_PERCPU to alloc_workqueue users

On Wed, Nov 12, 2025 at 6:02 PM Giovanni Cabiddu
<giovanni.cabiddu@...el.com> wrote:
>
> Hi Marco,
>
> On Fri, Nov 07, 2025 at 12:23:54PM +0100, Marco Crivellari wrote:
> > Currently if a user enqueues a work item using schedule_delayed_work() the
> > used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
> > WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
> > schedule_work() that is using system_wq and queue_work(), that makes use
> > again of WORK_CPU_UNBOUND.
> > This lack of consistency cannot be addressed without refactoring the API.
> The reference to WORK_CPU_UNBOUND in this paragraph got me a bit
> confused :-). As I understand it, if a workqueue is allocated with default
> parameters (i.e., no flags), it is per-CPU, so using queue_work() or
> queue_delayed_work() on such a queue would behave similarly to
> schedule_work() or schedule_delayed_work() in terms of CPU affinity.
>
> Is the `lack of consistency` you are referring in this paragraph about
> developer expectations?  IOW developers might assume they're getting
> unbound behavior?

Hi Giovanni,

Sorry for the confusion. The first paragraph is mostly to give some information
about the reason for the change.

It is correct what you are saying, indeed.
I will share the cover letter (for subsystem that needs one):

----
Let's consider a nohz_full system with isolated CPUs: wq_unbound_cpumask is
set to the housekeeping CPUs, for !WQ_UNBOUND the local CPU is selected.

This leads to different scenarios if a work item is scheduled on an
isolated CPU where "delay" value is 0 or greater then 0:
        schedule_delayed_work(, 0);

This will be handled by __queue_work() that will queue the work item on the
current local (isolated) CPU, while:

        schedule_delayed_work(, 1);

Will move the timer on an housekeeping CPU, and schedule the work there.
----

You can find more information and details at (also the reasons about the WQ
API change):

https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/

In short anyhow: that paragraph is not directly related to the changes
introduced here.
Here we only added explicitly WQ_PERCPU if WQ_UNBOUND is not present.

Thanks!

--

Marco Crivellari

L3 Support Engineer, Technology & Product