[PATCH] s390/hiperdispatch: use system_dfl_wq to reschedule hd_capacity_work

[PATCH] s390/hiperdispatch: use system_dfl_wq to reschedule hd_capacity_work

[Euan Bourke]

In hd_enable_hiperdispatch(), hd_capacity_work is scheduled on
system_dfl_wq, however the work function reschedules itself with
schedule_delayed_work(), which uses system_percpu_wq.

Hiperdispatch does not benefit from using the percpu workqueue. Use
mod_delayed_work() with system_dfl_wq for consistency.

Signed-off-by: Euan Bourke <euan@linux.ibm.com>
---
 arch/s390/kernel/hiperdispatch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/s390/kernel/hiperdispatch.c b/arch/s390/kernel/hiperdispatch.c
index 217206522266..2b9187e47217 100644
--- a/arch/s390/kernel/hiperdispatch.c
+++ b/arch/s390/kernel/hiperdispatch.c
@@ -265,7 +265,7 @@ static void hd_capacity_work_fn(struct work_struct *work)
 	}
 	trace_s390_hd_work_fn(steal_percentage, hd_entitled_cores, hd_high_capacity_cores);
 	mutex_unlock(&smp_cpu_state_mutex);
-	schedule_delayed_work(&hd_capacity_work, HD_DELAY_INTERVAL);
+	mod_delayed_work(system_dfl_wq, &hd_capacity_work, HD_DELAY_INTERVAL);
 }
 
 static int hiperdispatch_ctl_handler(const struct ctl_table *ctl, int write,
-- 
2.54.0

Re: [PATCH] s390/hiperdispatch: use system_dfl_wq to reschedule hd_capacity_work

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Replacing `schedule_delayed_work()` with `mod_delayed_work()` introduces a race condition that can inadvertently overwrite the longer initial delay set by `hd_enable_hiperdispatch()`.
--

commit 2fd466459ccefd111b375205c56ee7b3c6f6c69b
Author: Euan Bourke <euan@linux.ibm.com>

s390/hiperdispatch: use system_dfl_wq to reschedule hd_capacity_work

This commit updates hd_capacity_work to be rescheduled on system_dfl_wq
instead of system_percpu_wq. It accomplishes this by replacing
schedule_delayed_work() with mod_delayed_work().

> diff --git a/arch/s390/kernel/hiperdispatch.c b/arch/s390/kernel/hiperdispatch.c
> index 2172065222661..2b9187e472170 100644
> --- a/arch/s390/kernel/hiperdispatch.c
> +++ b/arch/s390/kernel/hiperdispatch.c
> @@ -265,7 +265,7 @@ static void hd_capacity_work_fn(struct work_struct *work)
>  	}
>  	trace_s390_hd_work_fn(steal_percentage, hd_entitled_cores, hd_high_capacity_cores);
>  	mutex_unlock(&smp_cpu_state_mutex);
> -	schedule_delayed_work(&hd_capacity_work, HD_DELAY_INTERVAL);
> +	mod_delayed_work(system_dfl_wq, &hd_capacity_work, HD_DELAY_INTERVAL);

[Severity: Medium]
Does replacing schedule_delayed_work() with mod_delayed_work() introduce a
race condition that could inadvertently overwrite the initial delay set by
hd_enable_hiperdispatch()?

If hd_capacity_work_fn() drops smp_cpu_state_mutex, and a concurrent CPU
topology update runs arch_update_cpu_topology() and acquires the mutex:

CPU 1:
hd_capacity_work_fn()
    mutex_unlock(&smp_cpu_state_mutex);
    <preempted or delayed>

CPU 2:
arch_update_cpu_topology()
    mutex_lock(&smp_cpu_state_mutex);
    hd_enable_hiperdispatch()
        mod_delayed_work(..., &hd_capacity_work, 1 second timer);

CPU 1:
    mod_delayed_work(system_dfl_wq, &hd_capacity_work, HD_DELAY_INTERVAL);

Could CPU 1 overwrite the longer 1-second delay set by CPU 2 with its
shorter 250ms timer (HD_DELAY_INTERVAL)?

The original schedule_delayed_work() internally uses queue_delayed_work(),
which safely ignores the queue request if the work is already pending,
preserving the longer interval. By switching to mod_delayed_work(), we now
unconditionally modify the timer.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260910075746.1233706-1-euan@linux.ibm.com?part=1