Re: [PATCH 2/4] ARM: cacheinfo: count external caches in early_cache_level()

From: sashiko-bot

Date: Sat Sep 12 2026 - 16:14:57 EST


Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Reallocation of cacheinfo memory via kzalloc_objs(..., GFP_ATOMIC) is called with interrupts disabled on secondary CPUs in big.LITTLE systems, which crashes on PREEMPT_RT.
--

commit 19c5ea8e9a4a8fc2bc601139e06e4ead6e749ab2
Author: Karl Mehltretter <kmehltretter@xxxxxxxxx>

ARM: cacheinfo: count external caches in early_cache_level()

This commit alters early_cache_level() to directly invoke
init_cache_level(). This includes device tree-described external
caches in the early allocation size, attempting to avoid late cacheinfo
reallocation on secondary CPUs which causes issues on PREEMPT_RT.

> diff --git a/arch/arm/kernel/cacheinfo.c b/arch/arm/kernel/cacheinfo.c
> index 860eeb03cfe5d..31591c9472548 100644
> --- a/arch/arm/kernel/cacheinfo.c
> +++ b/arch/arm/kernel/cacheinfo.c

[ ... ]

> @@ -146,6 +139,11 @@ int init_cache_level(unsigned int cpu)
> return 0;
> }
>
> +int early_cache_level(unsigned int cpu)
> +{
> + return init_cache_level(cpu);
> +}

[Severity: High]
This is a pre-existing issue, but does this CLIDR fallback path still leave
the kernel vulnerable to a panic on PREEMPT_RT if a secondary CPU happens to
have more cache leaves than the boot CPU?

On big.LITTLE ARM systems, if a secondary CPU has more cache leaves and no
device-tree cache specification is used, early_leaves will be smaller than
the required size. This forces a reallocation while interrupts are disabled
on the secondary CPU:

arch/arm/kernel/smp.c:secondary_start_kernel() {
...
trace_hardirqs_off();
...
update_siblings_masks(cpu);
}

drivers/base/arch_topology.c:update_siblings_masks() {
...
ret = detect_cache_attributes(cpuid);
}

drivers/base/cacheinfo.c:init_level_allocate_ci() {
...
if (cache_leaves(cpu) <= early_leaves && per_cpu_cacheinfo(cpu))
return 0;

kfree(per_cpu_cacheinfo(cpu));
return allocate_cache_info(cpu);
}

drivers/base/cacheinfo.c:allocate_cache_info() {
...
per_cpu_cacheinfo(cpu) = kzalloc_objs(struct cacheinfo,
cache_leaves(cpu), GFP_ATOMIC);
}

On PREEMPT_RT, memory allocation with GFP_ATOMIC relies on a sleepable
slab rt_mutex. Calling this with interrupts disabled results in a BUG
("sleeping function called from invalid context") and a system panic
during boot.

Could this reallocation path be avoided or deferred to a context where
interrupts are enabled for secondary CPUs?

--
Sashiko AI review · https://sashiko.dev/#/patchset/20260912195552.76673-1-kmehltretter@xxxxxxxxx?part=2