linux-kernel - Re: [PATCH 0/4] Workqueue: replace system wq and change 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: <CAAofZF7Ucv=c8Jy2j5C_JVZ_6=4eH=3QTrXO73JGUNCR4CoPNA@mail.gmail.com>
Date: Mon, 25 Aug 2025 12:38:10 +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 0/4] Workqueue: replace system wq and change
 alloc_workqueue callers

Hello Tejun,

> I'm having a bit of difficult time understanding the logic behind how the
> patches are laid out. This, while a bit tedious, shouldn't be that
> complicated:
>
> - Add all the new things to workqueue[.hc] so that the users can be
>   converted in whatever unit each subsystem wants. Note that this shouldn't
>   add any warnings or cause behavior changes. Just introduce new interface
>   and convert the subsystems clarifying that it's a noop change.
>
> - Once of the initial conversion pass is done and merged. Add warnings and
>   other mechanisms to get the stragglers and prevent further addition of old
>   interface. We can do this right after a merge window as a fix patch so
>   that we don't have to straddle multiple releases.
>
> - Go subsystem by subsystem and make the functional change you want to make
>   (here, converting from percpu to dfl). This can proceed without being
>   coupled with anything else.
>
> - After a cycle, drop the old interface.

Sounds good.
I will send a v2 of this series removing warnings and the mechanisms
inside __alloc_workqueue().

Many thanks!

Marco







On Thu, Aug 21, 2025 at 10:29 PM Tejun Heo <tj@...nel.org> wrote:
>
> Hello,
>
> On Thu, Aug 21, 2025 at 09:40:58AM +0200, Marco Crivellari wrote:
> > > On Tue, Aug 19, 2025 at 02:28:12PM +0200, Marco Crivellari wrote:
> > > > Another question / observation: I guess maintainers can't just pull
> > > > the changes and merge for the next release, if the workqueue changes
> > > > (e.g. changes in queue_work() etc) are not also merged, right?
> > > >
> > > > I received a reply here, in the meantime, in "Workqueue: fs: replace
> > > > use of system_wq and add WQ_PERCPU to alloc_workqueue users"
> > > > (https://www.spinics.net/lists/kernel/msg5811817.html).
> > >
> > > I can prepare a branch that fs can pull but aren't all the prerequisites
> > > already in the master branch from the last cycle?
> ...
> > There is still the logic inside "include/linux/workqueue.h", in
> > queue_delayed_work() / mod_delayed_work() / queue_work().
> > Just the pr_warn_once() and the workqueue redirection.
>
> These are not prerequisites, right? In fact, we should add the warnings only
> after most of the tree have already been converted.
>
> > These changes are introduced by 2 different patches, based on when the
> > two new wq(s) are replaced inside the code.
> >
> > There are also changes inside  __alloc_workqueue(), always in this
> > series (when WQ_PERCPU is used), because they are the "general" (core)
> > changes.
> >
> > If I remember correctly we decided to keep the prerequisites without
> > any more "logic".
> > As long as this series is merged before or anyhow in the same rc, I
> > think there are no problems; right?
>
> I'm having a bit of difficult time understanding the logic behind how the
> patches are laid out. This, while a bit tedious, shouldn't be that
> complicated:
>
> - Add all the new things to workqueue[.hc] so that the users can be
>   converted in whatever unit each subsystem wants. Note that this shouldn't
>   add any warnings or cause behavior changes. Just introduce new interface
>   and convert the subsystems clarifying that it's a noop change.
>
> - Once of the initial conversion pass is done and merged. Add warnings and
>   other mechanisms to get the stragglers and prevent further addition of old
>   interface. We can do this right after a merge window as a fix patch so
>   that we don't have to straddle multiple releases.
>
> - Go subsystem by subsystem and make the functional change you want to make
>   (here, converting from percpu to dfl). This can proceed without being
>   coupled with anything else.
>
> - After a cycle, drop the old interface.
>
> What not to do:
>
> - Don't make workqueue changes combined with a lot of changes to other
>   subsystems. Workqueue changes should come and after those, not together
>   with.
>
> Thanks.
>
> --
> tejun



--

Marco Crivellari

L3 Support Engineer, Technology & Product




marco.crivellari@...e.com