The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
Possible dependencies:
df5b035b5683 ("x86/cacheinfo: Add a cpu_llc_shared_mask() UP variant") 66558b730f25 ("sched: Add cluster scheduler level for x86")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From df5b035b5683d6a25f077af889fb88e09827f8bc Mon Sep 17 00:00:00 2001 From: Borislav Petkov bp@suse.de Date: Fri, 19 Aug 2022 19:47:44 +0200 Subject: [PATCH] x86/cacheinfo: Add a cpu_llc_shared_mask() UP variant
On a CONFIG_SMP=n kernel, the LLC shared mask is 0, which prevents __cache_amd_cpumap_setup() from doing the L3 masks setup, and more specifically from setting up the shared_cpu_map and shared_cpu_list files in sysfs, leading to lscpu from util-linux getting confused and segfaulting.
Add a cpu_llc_shared_mask() UP variant which returns a mask with a single bit set, i.e., for CPU0.
Fixes: 2b83809a5e6d ("x86/cpu/amd: Derive L3 shared_cpu_map from cpu_llc_shared_mask") Reported-by: Saurabh Sengar ssengar@linux.microsoft.com Signed-off-by: Borislav Petkov bp@suse.de Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/1660148115-302-1-git-send-email-ssengar@linux.micr...
diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h index 81a0211a372d..a73bced40e24 100644 --- a/arch/x86/include/asm/smp.h +++ b/arch/x86/include/asm/smp.h @@ -21,16 +21,6 @@ DECLARE_PER_CPU_READ_MOSTLY(u16, cpu_llc_id); DECLARE_PER_CPU_READ_MOSTLY(u16, cpu_l2c_id); DECLARE_PER_CPU_READ_MOSTLY(int, cpu_number);
-static inline struct cpumask *cpu_llc_shared_mask(int cpu) -{ - return per_cpu(cpu_llc_shared_map, cpu); -} - -static inline struct cpumask *cpu_l2c_shared_mask(int cpu) -{ - return per_cpu(cpu_l2c_shared_map, cpu); -} - DECLARE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_cpu_to_apicid); DECLARE_EARLY_PER_CPU_READ_MOSTLY(u32, x86_cpu_to_acpiid); DECLARE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_bios_cpu_apicid); @@ -172,6 +162,16 @@ extern int safe_smp_processor_id(void); # define safe_smp_processor_id() smp_processor_id() #endif
+static inline struct cpumask *cpu_llc_shared_mask(int cpu) +{ + return per_cpu(cpu_llc_shared_map, cpu); +} + +static inline struct cpumask *cpu_l2c_shared_mask(int cpu) +{ + return per_cpu(cpu_l2c_shared_map, cpu); +} + #else /* !CONFIG_SMP */ #define wbinvd_on_cpu(cpu) wbinvd() static inline int wbinvd_on_all_cpus(void) @@ -179,6 +179,11 @@ static inline int wbinvd_on_all_cpus(void) wbinvd(); return 0; } + +static inline struct cpumask *cpu_llc_shared_mask(int cpu) +{ + return (struct cpumask *)cpumask_of(0); +} #endif /* CONFIG_SMP */
extern unsigned disabled_cpus;
On Mon, Oct 03, 2022 at 08:20:27AM +0200, gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
Possible dependencies:
df5b035b5683 ("x86/cacheinfo: Add a cpu_llc_shared_mask() UP variant") 66558b730f25 ("sched: Add cluster scheduler level for x86")
This is a fix for CONFIG_SMP=n kernels which was caught by testing this explicitly by disabling SMP. IOW, I don't think anyone would be running SMP=n kernels and thus maybe should not backport those...?
Thx.
On Wed, Oct 05, 2022 at 12:45:19PM +0200, Borislav Petkov wrote:
On Mon, Oct 03, 2022 at 08:20:27AM +0200, gregkh@linuxfoundation.org wrote:
The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to stable@vger.kernel.org.
Possible dependencies:
df5b035b5683 ("x86/cacheinfo: Add a cpu_llc_shared_mask() UP variant") 66558b730f25 ("sched: Add cluster scheduler level for x86")
This is a fix for CONFIG_SMP=n kernels which was caught by testing this explicitly by disabling SMP. IOW, I don't think anyone would be running SMP=n kernels and thus maybe should not backport those...?
Yeah, I agree, this doesn't look like a valid thing to backport, if people had this issue in 5.15.y they would have already reported by now.
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org