linux-kernel - Re: [PATCH] workqueue: flush all pending jobs in destroy

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: <aA_JLyCkdH9koy55@slm.duckdns.org>
Date: Mon, 28 Apr 2025 08:30:07 -1000
From: Tejun Heo <tj@...nel.org>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Lai Jiangshan <jiangshanlai@...il.com>,
	Philipp Stanner <phasta@...lbox.org>,
	Danilo Krummrich <dakr@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] workqueue: flush all pending jobs in destroy_workqueue()

Hello, Alice.

On Mon, Apr 28, 2025 at 09:32:46AM +0000, Alice Ryhl wrote:
> Isn't that just going to be equal to WORK_CPU_UNBOUND most of the time?
> 
> Though I guess we could use the values NR_CPUS .. 2*NR_CPUS-1 to
> remember which list is used when it is unbound.

I think there are multiple ways to go about it. Maybe we can
wq_select_unbound_cpu() earlier. Maybe we can encode the unboundedness in a
flag bit, or we can just add another 32bit field to delayed_work. Given the
layout, I don't think adding another 32bit field would change the actual
size of delayed_work on 64bit machines anyway.

Thanks.

-- 
tejun