lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 12 Aug 2022 14:56:21 +0000
From:   "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
To:     Saurabh Sengar <ssengar@...ux.microsoft.com>,
        Saurabh Singh Sengar <ssengar@...rosoft.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
        "x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "tim.c.chen@...ux.intel.com" <tim.c.chen@...ux.intel.com>,
        "will@...nel.org" <will@...nel.org>,
        "song.bao.hua@...ilicon.com" <song.bao.hua@...ilicon.com>,
        "suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] x86/cacheinfo: Don't use cpu_llc_shared_map for
 !CONFIG_SMP

From: Saurabh Sengar <ssengar@...ux.microsoft.com> Sent: Wednesday, August 10, 2022 9:15 AM
> 
> cpu_llc_shared_map is always declared and defined, but populated in
> arch/x86/kernel/smpboot.c which only builds for CONFIG_SMP=y. For
> UniProcessor builds this mask is never populated and hence invalid.
> Current code doesn't handle the case of AMD UniProcessor correctly,
> which results "shared_cpu_map" and "shared_cpu_list" files missing from
> sysfs entries for l3 cache. This patch fixes this issue.
> This code used to work because of a another bug in 'cpumask_next',
> where in the CONFIG_SMP=n case the cpumask_next() ignores empty mask
> that results as if CPU 0 was set. This bug in 'cpumask_next' was fixed by
> following commit, which exposes the cpu_llc_shared_map bug.
> 
> b81dce77ced ("cpumask: Fix invalid uniprocessor mask assumption")
> 
> Fixes: 2b83809a5e ("x86/cpu/amd: Derive L3 shared_cpu_map from
> cpu_llc_shared_mask")
> Signed-off-by: Saurabh Sengar <ssengar@...ux.microsoft.com>
> ---
>  arch/x86/kernel/cpu/cacheinfo.c | 14 ++++++++++++--
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
> index 66556833d7af..8753bf33fec4 100644
> --- a/arch/x86/kernel/cpu/cacheinfo.c
> +++ b/arch/x86/kernel/cpu/cacheinfo.c
> @@ -889,10 +889,12 @@ static int __cache_amd_cpumap_setup(unsigned int cpu, int
> index,
>  	int i, sibling;
> 
>  	/*
> -	 * For L3, always use the pre-calculated cpu_llc_shared_mask
> -	 * to derive shared_cpu_map.
> +	 * For L3, in case of SMP systems use the pre-calculated
> +	 * cpu_llc_shared_mask to derive shared_cpu_map. In case
> +	 * of UP simply set the only cpu in mask.
>  	 */
>  	if (index == 3) {
> +#ifdef CONFIG_SMP
>  		for_each_cpu(i, cpu_llc_shared_mask(cpu)) {
>  			this_cpu_ci = get_cpu_cacheinfo(i);
>  			if (!this_cpu_ci->info_list)
> @@ -905,6 +907,14 @@ static int __cache_amd_cpumap_setup(unsigned int cpu, int
> index,
>  						&this_leaf->shared_cpu_map);
>  			}
>  		}
> +#else
> +		this_cpu_ci = get_cpu_cacheinfo(cpu);
> +		WARN_ON(!this_cpu_ci->info_list);
> +		if (!this_cpu_ci->info_list)
> +			return 0;
> +		this_leaf = this_cpu_ci->info_list + index;
> +		cpumask_set_cpu(cpu, &this_leaf->shared_cpu_map);
> +#endif
>  	} else if (boot_cpu_has(X86_FEATURE_TOPOEXT)) {
>  		unsigned int apicid, nshared, first, last;
> 
> --
> 2.25.1

Reviewed-by: Michael Kelley <mikelley@...rosoft.com>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ