linux-kernel - Re: [PATCH v3] workqueue: introduce queue_delayed_work_on_offline

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: <Z6TkjhgSgzzTnm4t@slm.duckdns.org>
Date: Thu, 6 Feb 2025 06:34:22 -1000
From: Tejun Heo <tj@...nel.org>
To: imran.f.khan@...cle.com
Cc: jiangshanlai@...il.com, haakon.bugge@...cle.com,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] workqueue: introduce
 queue_delayed_work_on_offline_safe

On Wed, Feb 05, 2025 at 11:54:20AM +1100, imran.f.khan@...cle.com wrote:
...
> The problem is for the cases where a CPU is already offline or in the
> middle of being offlined and past timers_dead_cpu callback. In such a
> scenario if someone puts a delayed work on this CPU, we have problem. 
> The WARN_ON_ONCE in [1] can indicate  this but the dwork's timer would
> still end up on the offlined cpu and will not be migrated (since CPU was
> past timer_dead state , when dwork was queued).
> 
> One way to avoid this is that we ask callers to do the needful (hotplug lock,
> hotplug callbacks) and ensure dwork does not end up on such offlined CPU.
> The other way (as attempted in this patch) would be to give such users an
> interface, that can ensure that  dwork never ends on on offlined CPU.

I don't think introducing a new interface makes sense here. Either the WARN
is enough or we can follow what queue_work_on() does and ensure that the
delayed work item gets executed *somewhere*.

Thanks.

-- 
tejun