linux-kernel - Re: [PATCH] workqueue: Always use wq_select_unbound_cpu() for WORK_CPU

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: <Z7iSboU-05uMJ7-e@localhost.localdomain>
Date: Fri, 21 Feb 2025 15:49:18 +0100
From: Frederic Weisbecker <frederic@...nel.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: open list <linux-kernel@...r.kernel.org>, Tejun Heo <tj@...nel.org>,
	Lai Jiangshan <jiangshanlai@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] workqueue: Always use wq_select_unbound_cpu() for
 WORK_CPU_UNBOUND.

Le Fri, Feb 21, 2025 at 12:20:03PM +0100, Sebastian Andrzej Siewior a écrit :
> If the user did not specify a CPU while enqueuing a work item then
> WORK_CPU_UNBOUND is passed. In this case, for WQ_UNBOUND a CPU is
> selected based on wq_unbound_cpumask while the local CPU is preferred.
> For !WQ_UNBOUND the local CPU is selected.
> For NOHZ_FULL system with isolated CPU wq_unbound_cpumask is set to the
> not isolated (housekeeping) CPUs. This leads to different behaviour if a
> work item is scheduled on an isolated CPU where
> 	schedule_delayed_work(, 1);
> 
> will move the timer to the housekeeping CPU and then schedule the work
> there (on the housekeeping CPU) while
> 	schedule_delayed_work(, 0);
> 
> will schedule the work item on the isolated CPU.
> 
> The documentation says WQ_UNBOUND prefers the local CPU. It can
> preferer the local CPU if it is part of wq_unbound_cpumask.
> 
> Restrict WORK_CPU_UNBOUND to wq_unbound_cpumask via
> wq_select_unbound_cpu().
> 
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>

I really would like to have this patch in. I have considered
doing that a few month ago but got sort-of discouraged by the
lack of properly defined semantics for schedule_work(). And that
function has too many users to check their locality assumptions.

Its headers advertize to queue in global workqueue but the target
is system_wq and not system_unbound_wq. But then it's using
WORK_CPU_UNBOUND through queue_work().

I'm tempted to just assume that none of its users depend on the
work locality?

Thanks.

> ---
>  kernel/workqueue.c | 8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index bfe030b443e27..134d9550538aa 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -2261,12 +2261,8 @@ static void __queue_work(int cpu, struct workqueue_struct *wq,
>  	rcu_read_lock();
>  retry:
>  	/* pwq which will be used unless @work is executing elsewhere */
> -	if (req_cpu == WORK_CPU_UNBOUND) {
> -		if (wq->flags & WQ_UNBOUND)
> -			cpu = wq_select_unbound_cpu(raw_smp_processor_id());
> -		else
> -			cpu = raw_smp_processor_id();
> -	}
> +	if (req_cpu == WORK_CPU_UNBOUND)
> +		cpu = wq_select_unbound_cpu(raw_smp_processor_id());
>  
>  	pwq = rcu_dereference(*per_cpu_ptr(wq->cpu_pwq, cpu));
>  	pool = pwq->pool;
> -- 
> 2.47.2
>