[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yv1ELaWHbRfvdt/p@zn.tnic>
Date: Wed, 17 Aug 2022 21:40:29 +0200
From: Borislav Petkov <bp@...en8.de>
To: Saurabh Sengar <ssengar@...ux.microsoft.com>
Cc: ssengar@...rosoft.com, mikelley@...rosoft.com, tglx@...utronix.de,
mingo@...hat.com, dave.hansen@...ux.intel.com, x86@...nel.org,
hpa@...or.com, peterz@...radead.org, tim.c.chen@...ux.intel.com,
will@...nel.org, song.bao.hua@...ilicon.com,
suravee.suthikulpanit@....com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/cacheinfo: Don't use cpu_llc_shared_map for
!CONFIG_SMP
On Wed, Aug 10, 2022 at 09:15:15AM -0700, Saurabh Sengar wrote:
> 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,
What is "AMD UniProcessor"?
> which results "shared_cpu_map" and "shared_cpu_list" files missing from
> sysfs entries for l3 cache. This patch fixes this issue.
What issue exactly?
What is the real life use case for this?
> 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")
Add
---
[core]
abbrev = 12
[alias]
one = show -s --pretty='format:%h (\"%s\")'
---
to your git .config so that when you do
$ git one <commit id>
you can get the proper formatting and abbreviated sha1 for commits.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists