linux-kernel - Re: [PATCH v2 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: <CAAofZF6AfmjYcNQSBFHsteN_10=z0RSt20DpOM8i_NLQBO5qLQ@mail.gmail.com>
Date: Tue, 10 Jun 2025 10:34:15 +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>, Michal Hocko <mhocko@...e.com>
Subject: Re: [PATCH v2 0/4] Workqueue: rename system workqueue and add WQ_PERCPU

Hello Tejun,

Thanks!

Let's see if I understood what you mean.

>- Separate out patches to add the new flag and wq. Don't add the warnings
>  yet. I'll commit these patches to a separate wq branch.

Basically these means have 2 more patches, one for WQ_PERCPU (only the
new flag, like in the v1 let's say) and another patch that adds the wq(s).

So, all the logic changes (also in __alloc_workqueue), pr_warn_once() will
stay in the other patch (that you will apply later); this is not only 1 patch,
following your next point.

If I understood correctly, it makes sense to me.

>- Split out patches by subsystems. I know this is tedious but think it'd
> still be worth doing. It doesn't have to be completely granular. e.g. We
> know that network changes go through a single tree, so all network changes
>  can be in a single patch. Each patch can explain the workqueue changes and
>  that the patch can be either routed through the subysstem which would
>  require pulling from the above wq branch, or, as the default option, we'd
>  be happy to route the patch through the workqueue tree. I can create a
>  separate branch to collect the conversion patches that can go through wq
>  tree.

This impacts patch 3, so instead of 1 big patch, you are thinking of N patches,
in order to add WQ_PERCPU to the callers of subsystems first.

So, something like:
- net/
- mm/
- fs/

Do you have something different in mind?

>- After the next rc1 drops, I can apply the patches to add warnings to the
>  -fixes branch and then send them to Linus.

Sounds good.

Thank you again.

On Mon, Jun 9, 2025 at 8:59 PM Tejun Heo <tj@...nel.org> wrote:
>
> Hello, Marco.
>
> On Mon, Jun 09, 2025 at 12:35:31PM +0200, Marco Crivellari wrote:
> > === Introduced Changes by this patchset ===
> >
> > 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.
> >
> >               Because of that, system_wq has been renamed in system_percpu_wq,
> >               while system_unbound_wq is now system_dfl_wq.
> >
> >               The old wq are still around, but if used in queue_work(), a pr_warn_once()
> >               will be printed and the wq used is automatically assigned to the new
> >               default (system_dfl_wq or system_percpu_wq).
> >
> > 2)  [P 3] Introduction of WQ_PERCPU.
> >
> >               This patch adds the new WQ_PERCPU flag to explicitly require to be per-cpu.
> >
> >               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.
> >
> >               WQ_UNBOUND will be removed in a next release cycle.
> >
> >               Because of that, this patch also adds to every alloc_workqueue() caller
> >               that require it, the new WQ_PERCPU flag.
> >
> > 3)  [P 4] WQ_PERCPU documented in workqueue.rst
> >
> >               Added a short section about WQ_PERCPU and a Note under WQ_UNBOUND
> >               mentioning that it will be removed in the future.
>
> Thanks for working on this and the changes generally make sense to me.
> However, I think we should try a bit harder to reduce friction with the
> affected subsystems. It's a bit unfortunate that we're already at rc1. It
> would have been better if the new flags and wq were introduced before rc1.
> Oh well, we can manage. How about something like this?
>
> - Separate out patches to add the new flag and wq. Don't add the warnings
>   yet. I'll commit these patches to a separate wq branch.
>
> - Split out patches by subsystems. I know this is tedious but think it'd
>   still be worth doing. It doesn't have to be completely granular. e.g. We
>   know that network changes go through a single tree, so all network changes
>   can be in a single patch. Each patch can explain the workqueue changes and
>   that the patch can be either routed through the subysstem which would
>   require pulling from the above wq branch, or, as the default option, we'd
>   be happy to route the patch through the workqueue tree. I can create a
>   separate branch to collect the conversion patches that can go through wq
>   tree.
>
> - After the next rc1 drops, I can apply the patches to add warnings to the
>   -fixes branch and then send them to Linus.
>
> This is a bit more work but would likely produce less friction without
> delaying the timeline significantly.
>
> Thanks.
>
> --
> tejun



--

Marco Crivellari

L3 Support Engineer, Technology & Product




marco.crivellari@...e.com