linux-kernel - Re: [PATCH 1/2] workqueue: Use pwq->work_color for 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: <aS8j9qq7L38lNsuL@slm.duckdns.org>
Date: Tue, 2 Dec 2025 07:37:58 -1000
From: Tejun Heo <tj@...nel.org>
To: Lai Jiangshan <jiangshanlai@...il.com>
Cc: linux-kernel@...r.kernel.org,
	Lai Jiangshan <jiangshan.ljs@...group.com>
Subject: Re: [PATCH 1/2] workqueue: Use pwq->work_color for wq_barrier

Hello,

On Tue, Nov 25, 2025 at 06:31:24PM +0800, Lai Jiangshan wrote:
> From: Lai Jiangshan <jiangshan.ljs@...group.com>
> 
> wq_barrier work items are internal and do not count as user work items.
> They do not participate in flush_workqueue() except for a sanity check,
> since wq_barrier owns the PWQ reference. Therefore, any work color is
> acceptable; just use the latest pwq->work_color.

Maybe it is but I really don't like it. It becomes a lot harder to think
about and that makes things more fragile in the long term. I think it should
either not participate at all or do something straightforward like
inheriting the color of the work item it's flushing.

Even just thinking about the original problem that added flush color to
barrier work items becomes trickier. We can no longer just think that "oh
yeah, no new work items and all barriers match the target work items, so
flushing should wait for the whole thing". It now becomes "what happens if a
new flush_work() is queued after the latest flush_workqueue()? does that
still wait for that new barrier item?". In fact, I'm not sure it does. So,
please don't do this. Let's keep things conceptually straightforward as much
as possible even if that costs a bit more code. Code is often a lot cheaper
than cognitive overhead.

Thanks.

-- 
tejun