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: <aKeBr3eBfh0wr_fH@slm.duckdns.org>
Date: Thu, 21 Aug 2025 10:29:35 -1000
From: Tejun Heo <tj@...nel.org>
To: Marco Crivellari <marco.crivellari@...e.com>
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,

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