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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAAofZF60A82utmB2LiVw910cdFDiHd+fPaozUKpQwfXUqv7R_g@mail.gmail.com>
Date: Tue, 6 May 2025 12:10:18 +0200
From: Marco Crivellari <marco.crivellari@...e.com>
To: Tejun Heo <tj@...nel.org>
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

Hi,

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

Sure, thanks for the advice.

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

Good, sounds fine.
But I don't understand where printk_once() should be placed.
Can you give me some further guidance?

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

Ok, so warn (printk_once()) if both flags are present but if none among
WQ_UNBOUND nor WQ_PERCPU are present, assume WQ_PERCPU.

Did I understand correctly?

> Do you mean caller?

Yes, sorry. I meant "every alloc_workqueue() caller".

> How is 3) different from 2)?

I get your point, I will use a single patch.

Many thanks in advance, about my questions.


On Tue, May 6, 2025 at 1:39 AM Tejun Heo <tj@...nel.org> wrote:
>
> 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



--

Marco Crivellari

L3 Support Engineer, Technology & Product




marco.crivellari@...e.com