# Re: \[PATCH v13 01/13\] sched/cputime: Add kcpustat\_field\_total helper

- From: sashiko-bot@kernel.org
- Date: 2026-09-09 14:16:12 
- List: virtualization
- Page: https://ratatoskr.run/virtualization/2026/09/17539493
- Thread: https://ratatoskr.run/virtualization/2026/09/17538960/t.md

```text
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Splitting a single iteration loop into two independent passes over a concurrently modified cpumask introduces a TOCTOU race, causing a mismatch between accumulated steal time and CPU count.
--

commit f4767f1bec53619b21fdac4c5195173936031ed9
Author: Shrikanth Hegde [ref]

sched/cputime: Add kcpustat_field_total helper

This commit introduces a new helper function kcpustat_field_total() to sum up
a given cpustat over a specified cpumask. It then refactors existing code in
the s390 hiperdispatch and procfs uptime to use this helper to simplify the
code and avoid duplication.

> 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: Medium]
Does splitting this single loop into two independent passes over
hd_vmvl_cpumask introduce a race condition?

If CPU hotplug operations modify hd_vmvl_cpumask concurrently between the calls
to kcpustat_field_total() and cpumask_weight(), could this result in a
mismatched numerator and denominator?

For example, the first read could see a large mask, while the second read sees
a smaller mask. This mismatch can cause transient artificial spikes in the
steal percentage.

Could this incorrectly trigger a scheduler domain rebuild
(topology_schedule_update()) and lead to an unnecessary performance degradation
during CPU hotplug operations?

>  	/*
>  	 * If there is no vertical medium and low CPUs steal time
>  	 * is 0 as vertical high CPUs shouldn't experience steal time.

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