On 12/29/22 17:47, Krzysztof Kozlowski wrote:
On 09/12/2022 11:31, Pierre Gondois wrote:v2: - Applied renaming/formatting comments from v1. - Check CACHE_TYPE_VALID flag in pppt.c. v3: - Applied Sudeep's suggestions (for patch 5/5): - Renaming allocate_cache_info() -> fecth_cache_info() - Updated error message - Extract an inline allocate_cache_info() function - Re-run checkpatch with --strict option Note: This patchset requires the following patch to be applied first in order to avoid the same bug described in the commit message: https://lore.kernel.org/all/20221116094958.2141072-1-pierre.gondois@xxxxxxx/ [1] and [2] build the CPU topology from the cacheinfo information for both DT/ACPI based systems and remove (struct cpu_topology).llc_id which was used by ACPI only. Creating the cacheinfo for secondary CPUs is done during early boot. Preemption and interrupts are disabled at this stage. On PREEMPT_RT kernels, allocating memory (and parsing the PPTT table for ACPI based systems) triggers a: 'BUG: sleeping function called from invalid context' [4] To prevent this bug, allocate the cacheinfo from the primary CPU when preemption and interrupts are enabled and before booting secondary CPUs. The cache levels/leaves are computed from DT/ACPI PPTT information only, without relying on the arm64 CLIDR_EL1 register. If no cache information is found in the DT/ACPI PPTT, then fallback to the current state, triggering [4] on PREEMPT_RT kernels. Patches to update the arm64 device trees that have incomplete cacheinfo (mostly for missing the 'cache-level' or 'cache-unified' property) have been sent at [3]. Tested platforms: - ACPI + PPTT: Ampere Altra, Ampere eMAG, Cavium ThunderX2, Kunpeng 920, Juno-r2 - DT: rb5, db845c, Juno-r2I gave the patchset a try with DTS fixes for cache topology on Qualcomm RB5 board (SM8250 SoC) and with KASAN it produces: BUG: KASAN: slab-out-of-bounds in populate_cache_leaves+0x84/0x15c [ 0.633014] dump_backtrace.part.0+0xe0/0xf0 [ 0.633035] show_stack+0x18/0x40 [ 0.633050] dump_stack_lvl+0x8c/0xb8 [ 0.633085] print_report+0x188/0x488 [ 0.633106] kasan_report+0xac/0xf0 [ 0.633136] __asan_store4+0x80/0xa4 [ 0.633158] populate_cache_leaves+0x84/0x15c [ 0.633181] detect_cache_attributes+0xc0/0x8c4 [ 0.633213] update_siblings_masks+0x28/0x43c [ 0.633235] store_cpu_topology+0x98/0xc0 [ 0.633251] smp_prepare_cpus+0x2c/0x15c [ 0.633281] kernel_init_freeable+0x22c/0x424 [ 0.633310] kernel_init+0x24/0x13c [ 0.633328] ret_from_fork+0x10/0x20 [ 0.633388] [ 0.708729] Allocated by task 1: [ 0.712078] kasan_save_stack+0x2c/0x60 [ 0.716066] kasan_set_track+0x2c/0x40 [ 0.719959] kasan_save_alloc_info+0x24/0x3c [ 0.724387] __kasan_kmalloc+0xa0/0xbc [ 0.728278] __kmalloc+0x74/0x110 [ 0.731740] fetch_cache_info+0x170/0x210 [ 0.735902] init_cpu_topology+0x254/0x2bc [ 0.740171] smp_prepare_cpus+0x20/0x15c [ 0.744272] kernel_init_freeable+0x22c/0x424 [ 0.748791] kernel_init+0x24/0x13c [ 0.752420] ret_from_fork+0x10/0x20 Best regards, Krzysztof
Hello Krzysztof, Thanks for trying the patch-set and reporting the issue. Hopefully the v4 should solve this: https://lore.kernel.org/all/20230104183033.755668-1-pierre.gondois@xxxxxxx/ I will also try to follow the corresponding dts modifications, Regards, Pierre
