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

[sashiko-bot@kernel.org]

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@gmail.com>

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@gmail.com?part=2