Re: [PATCH v14 01/13] sched/cputime: Add kcpustat_field_total helper

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] s390/hiperdispatch: TOCTOU race in hd_calculate_steal_percentage() causes artificial steal percentage spikes
--

commit 543d41ec158ad38d026cd1a0e58754cc9393d347
Author: Shrikanth Hegde <sshegde@linux.ibm.com>

sched/cputime: Add kcpustat_field_total helper

This patch introduces a new helper function to sum up a given cpustat type
over a specified cpumask. It replaces the open-coded steal calculation in
s390 hiperdispatch and idle time calculation in proc uptime to simplify
the callers.

> diff --git a/arch/s390/kernel/hiperdispatch.c b/arch/s390/kernel/hiperdispatch.c
> index 2172065222661..c21496f0a141a 100644
> --- a/arch/s390/kernel/hiperdispatch.c
> +++ b/arch/s390/kernel/hiperdispatch.c

[ ... ]

> @@ -207,16 +207,12 @@ static unsigned long hd_calculate_steal_percentage(void)
>  {
>  	unsigned long time_delta, steal_delta, steal, percentage;
>  	static ktime_t prev;
> -	int cpus, cpu;
> +	int cpus;
>  	ktime_t now;
>  
> -	cpus = 0;
> -	steal = 0;
>  	percentage = 0;
> -	for_each_cpu(cpu, &hd_vmvl_cpumask) {
> -		steal += kcpustat_cpu(cpu).cpustat[CPUTIME_STEAL];
> -		cpus++;
> -	}
> +	steal = kcpustat_field_total(CPUTIME_STEAL, &hd_vmvl_cpumask);
> +	cpus = cpumask_weight(&hd_vmvl_cpumask);

[Severity: High]
Could separating the summation from the divisor count open a race window
against concurrent mask updates?

In the previous single-loop calculation, the total steal time and CPU count
were evaluated together on a stable view of the mask. With these changes,
if a concurrent CPU hotplug event calls update_cpu_masks() while
hd_calculate_steal_percentage() is running, hd_vmvl_cpumask could be cleared
and repopulated asynchronously.

If the mask changes from multiple CPUs to 1 CPU between the
kcpustat_field_total calculation and the cpumask_weight call, steal will
reflect the delta of the larger number of CPUs, but cpus will evaluate to 1.

Because the percentage is computed as steal_delta / cpus, dividing the
larger steal_delta by 1 would artificially inflate the steal percentage.
Can this erroneous spike trip the hd_steal_threshold, causing the scheduler
topology to wrongly disable Hiperdispatch and downgrade high-capacity cores?

[ ... ]

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