Re: [PATCH 08/23] arm64: topology: Use RCU to protect access to HK_TYPE_TICK cpumask

sashiko-bot
2026-04-22T03:09:01Z

Sashiko AI review found 1 potential issue(s):
- [High] The `hk_cpu` variable is evaluated only once outside the `while (1)` loop, causing it to use stale housekeeping status when iterating over fallback CPUs.
--

commit ad2cf9abc3cffbdb84c73b305a44e5027c5f5e64
Author: Waiman Long <longman@redhat.com>

arm64: topology: Use RCU to protect access to HK_TYPE_TICK cpumask

This commit uses RCU to protect access to the HK_TYPE_TICK cpumask to
prevent it from going away in the middle of the operation.

> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> index b32f13358fbb1..48f1508016895 100644
> --- a/arch/arm64/kernel/topology.c
> +++ b/arch/arm64/kernel/topology.c
[ ... ]
> @@ -187,11 +188,16 @@ int arch_freq_get_on_cpu(int cpu)
> unsigned int start_cpu = cpu;
> unsigned long last_update;
> unsigned int freq = 0;
> + bool hk_cpu;
> u64 scale;
>
> if (!amu_fie_cpu_supported(cpu) || !arch_scale_freq_ref(cpu))
> return -EOPNOTSUPP;
>
> + scoped_guard(rcu) {
> + hk_cpu = housekeeping_cpu(cpu, HK_TYPE_TICK);
> + }
> +
> while (1) {
>
> amu_sample = per_cpu_ptr(&cpu_amu_samples, cpu);
> @@ -204,16 +210,21 @@ int arch_freq_get_on_cpu(int cpu)
> * (and thus freq scale), if available, for given policy: this boils
> * down to identifying an active cpu within the same freq domain, if any.
> */
> - if (!housekeeping_cpu(cpu, HK_TYPE_TICK) ||
> + if (!hk_cpu ||
> time_is_before_jiffies(last_update + msecs_to_jiffies(AMU_SAMPLE_EXP_MS))) {
> struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);

Since hk_cpu is evaluated outside the while loop, does it use the
housekeeping status of the initial start_cpu for all iterations?

If the start_cpu is tickless (hk_cpu == false), it appears !hk_cpu will
remain permanently true for all loop iterations. This would cause the loop
to unconditionally reject every fallback cpu and eventually return -EAGAIN.

Conversely, if start_cpu is a housekeeping CPU with a stale sample, it
might improperly accept a tickless fallback cpu since hk_cpu remains true.

Should the hk_cpu evaluation be moved inside the while loop so it is
re-evaluated when the cpu variable changes?

--
Sashiko AI review · https://sashiko.dev/#/patchset/20260421030351.281436-1-longman@redhat.com?part=8