FAILED: patch "[PATCH] x86/cacheinfo: Add a cpu_llc_shared_mask() UP variant" failed to apply to 5.15-stable tree
Subsystems (2)
[email protected]
maintainerThe 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 <[email protected]>.
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 <[email protected]>
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.
arch/x86/include/asm/smp.h +15 -10
@@ -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;
Quoted 10 lines · On Mon, Oct 03, 2022 at 08:20:27AM +0200, [email protected] 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 <[email protected]>.Possible dependencies:
df5b035b5683("x86/cacheinfo: Add acpu_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.
Signature · 6 lines
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
(HRB 36809, AG Nürnberg)Greg KH
maintainerQuoted 7 lines · Borislav Petkov
Quoted 6 lines · On Mon, Oct 03, 2022 at 08:20:27AM +0200, [email protected] 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 <[email protected]>.
Quoted 8 lines
Quoted 4 lines
Possible dependencies:
df5b035b5683("x86/cacheinfo: Add acpu_llc_shared_mask()UP variant")66558b730f25("sched: Add cluster scheduler level for x86")This is a fix for
CONFIG_SMP=nkernels 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