kernel/linux.git/drivers/base/cacheinfo.c, branch v6.2.6

cacheinfo: Fix shared_cpu_map to handle shared caches at different levels

2023-03-11T12:50:39+00:00

[ Upstream commit 198102c9103fc78d8478495971947af77edb05c1 ] The cacheinfo sets up the shared_cpu_map by checking whether the caches with the same index are shared between CPUs. However, this will trigger slab-out-of-bounds access if the CPUs do not have the same cache hierarchy. Another problem is the mismatched shared_cpu_map when the shared cache does not have the same index between CPUs. CPU0 I D L3 index 0 1 2 x ^ ^ ^ ^ index 0 1 2 3 CPU1 I D L2 L3 This patch checks each cache is shared with all caches on other CPUs. Reviewed-by: Pierre Gondois Signed-off-by: Yong-Xuan Wang Link: https://lore.kernel.org/r/20230117105133.4445-2-yongxuan.wang@sifive.com Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin

cacheinfo: Remove of_node_put() for fw_token

2022-11-23T19:03:51+00:00

fw_token is used for DT/ACPI systems to identify CPUs sharing caches. For DT based systems, fw_token is set to a pointer to a DT node. commit 3da72e18371c ("cacheinfo: Decrement refcount in cache_setup_of_node()") doesn't increment the refcount of fw_token anymore in cache_setup_of_node(). fw_token is indeed used as a token and not as a (struct device_node*), so no reference to fw_token should be kept. However, [1] is triggered when hotplugging a CPU multiple times since cache_shared_cpu_map_remove() decrements the refcount to fw_token at each CPU unplugging, eventually reaching 0. Remove of_node_put() for fw_token in cache_shared_cpu_map_remove(). [1] ------------[ cut here ]------------ refcount_t: saturated; leaking memory. WARNING: CPU: 4 PID: 32 at lib/refcount.c:22 refcount_warn_saturate (lib/refcount.c:22 (discriminator 3)) Modules linked in: CPU: 4 PID: 32 Comm: cpuhp/4 Tainted: G W 6.1.0-rc1-14091-g9fdf2ca7b9c8 #76 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Oct 31 2022 pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : refcount_warn_saturate (lib/refcount.c:22 (discriminator 3)) lr : refcount_warn_saturate (lib/refcount.c:22 (discriminator 3)) [...] Call trace: [...] of_node_release (drivers/of/dynamic.c:335) kobject_put (lib/kobject.c:677 lib/kobject.c:704 ./include/linux/kref.h:65 lib/kobject.c:721) of_node_put (drivers/of/dynamic.c:49) free_cache_attributes.part.0 (drivers/base/cacheinfo.c:712) cacheinfo_cpu_pre_down (drivers/base/cacheinfo.c:718) cpuhp_invoke_callback (kernel/cpu.c:247 (discriminator 4)) cpuhp_thread_fun (kernel/cpu.c:785) smpboot_thread_fn (kernel/smpboot.c:164 (discriminator 3)) kthread (kernel/kthread.c:376) ret_from_fork (arch/arm64/kernel/entry.S:861) ---[ end trace 0000000000000000 ]--- Fixes: 3da72e18371c ("cacheinfo: Decrement refcount in cache_setup_of_node()") Reported-by: Geert Uytterhoeven Reported-by: Marek Szyprowski Tested-by: Geert Uytterhoeven Tested-by: Sudeep Holla Reviewed-by: Sudeep Holla Signed-off-by: Pierre Gondois Link: https://lore.kernel.org/r/20221116094958.2141072-1-pierre.gondois@arm.com Signed-off-by: Greg Kroah-Hartman

cacheinfo: Decrement refcount in cache_setup_of_node()

2022-11-10T17:33:28+00:00

Refcounts to DT nodes are only incremented in the function and never decremented. Decrease the refcounts when necessary. Signed-off-by: Pierre Gondois Reviewed-by: Sudeep Holla Link: https://lore.kernel.org/r/20221026185954.991547-1-pierre.gondois@arm.com Signed-off-by: Greg Kroah-Hartman

cacheinfo: Use atomic allocation for percpu cache attributes

2022-07-22T08:04:42+00:00

On couple of architectures like RISC-V and ARM64, we need to detect cache attribues quite early during the boot when the secondary CPUs start. So we will call detect_cache_attributes in the atomic context and since use of normal allocation can sleep, we will end up getting "sleeping in the atomic context" bug splat. In order avoid that, move the allocation to use atomic version in preparation to move the actual detection of cache attributes in the CPU hotplug path which is atomic. Cc: Ionela Voinescu Tested-by: Conor Dooley Signed-off-by: Sudeep Holla Link: https://lore.kernel.org/r/20220720-arch_topo_fixes-v3-1-43d696288e84@arm.com Signed-off-by: Greg Kroah-Hartman

cacheinfo: Align checks in cache_shared_cpu_map_{setup,remove} for readability

2022-07-04T15:22:28+00:00

The checks to skip the CPU itself or no cacheinfo case are implemented bit differently though the effect is exactly same. Just align the implementation in both cache_shared_cpu_map_{setup,remove} just for improved readability. No functional change. Link: https://lore.kernel.org/r/20220704101605.1318280-9-sudeep.holla@arm.com Tested-by: Conor Dooley Signed-off-by: Sudeep Holla

cacheinfo: Use cache identifiers to check if the caches are shared if available

2022-07-04T15:22:28+00:00

The cache identifiers is an optional property on most of the platforms. The presence of one must be indicated by the CACHE_ID valid bit in the attributes. We can use the cache identifiers provided by the firmware to check if any two cpus share the same cache instead of relying on the fw_token generated and set in the OS. Link: https://lore.kernel.org/r/20220704101605.1318280-8-sudeep.holla@arm.com Tested-by: Ionela Voinescu Tested-by: Conor Dooley Signed-off-by: Sudeep Holla

cacheinfo: Allow early detection and population of cache attributes

2022-07-04T15:22:28+00:00

Some architecture/platforms may need to setup cache properties very early in the boot along with other cpu topologies so that all these information can be used to build sched_domains which is used by the scheduler. Allow detect_cache_attributes to be called quite early during the boot. Link: https://lore.kernel.org/r/20220704101605.1318280-7-sudeep.holla@arm.com Tested-by: Ionela Voinescu Tested-by: Conor Dooley Reviewed-by: Gavin Shan Signed-off-by: Sudeep Holla

cacheinfo: Add support to check if last level cache(LLC) is valid or shared

2022-07-04T15:22:28+00:00

It is useful to have helper to check if the given two CPUs share last level cache. We can do that check by comparing fw_token or by comparing the cache ID. Currently we check just for fw_token as the cache ID is optional. This helper can be used to build the llc_sibling during arch specific topology parsing and feeding information to the sched_domains. This also helps to get rid of llc_id in the CPU topology as it is sort of duplicate information. Also add helper to check if the llc information in cacheinfo is valid or not. Link: https://lore.kernel.org/r/20220704101605.1318280-6-sudeep.holla@arm.com Tested-by: Ionela Voinescu Tested-by: Conor Dooley Reviewed-by: Gavin Shan Signed-off-by: Sudeep Holla

cacheinfo: Move cache_leaves_are_shared out of CONFIG_OF

2022-07-04T15:22:28+00:00

cache_leaves_are_shared is already used even with ACPI and PPTT. It checks if the cache leaves are the shared based on fw_token pointer. However it is defined conditionally only if CONFIG_OF is enabled which is wrong. Move the function cache_leaves_are_shared out of CONFIG_OF and keep it generic. It also handles the case where both OF and ACPI is not defined. Link: https://lore.kernel.org/r/20220704101605.1318280-5-sudeep.holla@arm.com Tested-by: Ionela Voinescu Tested-by: Conor Dooley Reviewed-by: Gavin Shan Signed-off-by: Sudeep Holla

cacheinfo: Add helper to access any cache index for a given CPU

2022-07-04T15:22:28+00:00

The cacheinfo for a given CPU at a given index is used at quite a few places by fetching the base point for index 0 using the helper per_cpu_cacheinfo(cpu) and offsetting it by the required index. Instead, add another helper to fetch the required pointer directly and use it to simplify and improve readability. Link: https://lore.kernel.org/r/20220704101605.1318280-4-sudeep.holla@arm.com Tested-by: Ionela Voinescu Tested-by: Conor Dooley Reviewed-by: Gavin Shan Signed-off-by: Sudeep Holla