From: sashiko-bot@kernel.org
To: "Pasha Tatashin" <pasha.tatashin@soleen.com>,
kees@kernel.org, rppt@kernel.org, juri.lelli@redhat.com,
nik.borisov@suse.com, tglx@kernel.org, vschneid@redhat.com,
kprateek.nayak@amd.com, vincent.guittot@linaro.org, bp@alien8.de,
jpoimboe@kernel.org, tony.luck@intel.com, david@kernel.org,
mingo@redhat.com, akpm@linux-foundation.org, linux-mm@kvack.org,
seanjc@google.com, ljs@kernel.org, zhangguopeng@kylinos.cn,
dietmar.eggemann@arm.com, mhocko@suse.com,
vinicius.gomes@intel.com, vbabka@kernel.org,
peterz@infradead.org, surenb@google.com, hpa@zytor.com,
x86@kernel.org, dmatlack@google.com, tim.c.chen@linux.intel.com,
kexec@lists.infradead.org, pratyush@kernel.org,
dave.hansen@linux.intel.com, rostedt@goodmis.org,
gmonaco@redhat.com, jgross@suse.com, mgorman@suse.de,
graf@amazon.com, liam@infradead.org, ridong.chen@linux.dev,
blum@kernel.org, longman@redhat.com, bsegall@google.com
Cc: tj@kernel.org, hannes@cmpxchg.org, mkoutny@suse.com
Subject: Re: [PATCH v2 3/8] x86/mce/intel: Bound cmci_rediscover() to a single topology peer
Date: Tue, 20 Oct 2026 01:15:47 +0000 [thread overview]
Message-ID: <sashiko-outbox-178404@kernel.org> (raw)
In-Reply-To: <20261019011446.834487-4-pasha.tatashin@soleen.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] x86/mce/intel: missing LLC topology level in cmci_clear() peer selection
- [Medium] x86/mce/intel: cmci_rediscover() leaves shared banks unclaimed on hybrid CPUs
--
commit cb9d97fffee1a97a8d921b6c7ed854215ee3231b
Author: Pasha Tatashin <pasha.tatashin@soleen.com>
x86/mce/intel: Bound cmci_rediscover() to a single topology peer
This commit optimizes CPU offline CMCI bank rediscovery by recording
orphaned banks in cmci_clear(), selecting a single online topology peer,
and probing only that target peer via smp_call_function_single() in
cmci_rediscover() instead of broadcasting to all online CPUs with
on_each_cpu().
> diff --git a/arch/x86/kernel/cpu/mce/intel.c b/arch/x86/kernel/cpu/mce/intel.c
> index 4655223ba5606..f57718b097d9b 100644
> --- a/arch/x86/kernel/cpu/mce/intel.c
> +++ b/arch/x86/kernel/cpu/mce/intel.c
[ ... ]
> @@ -346,8 +353,31 @@ void cmci_clear(void)
> if (!cmci_supported(&banks))
> return;
> raw_spin_lock_irqsave(&cmci_discover_lock, flags);
> + bitmap_zero(cmci_orphaned_banks, MAX_NR_BANKS);
> + /*
> + * A bank is shared by the CPUs of one SMT core, L2 cluster, die or
> + * package, and these scopes nest. The first online peer found from
> + * the innermost scope outwards is therefore part of every sharing
> + * scope that still has an online CPU, so it alone can claim every
> + * orphaned bank that is still claimable. If it already owns an index,
> + * the instance released here is not shared with it, hence not with
> + * any online CPU, and that index can be dropped from the rediscovery.
> + */
> + target = cpumask_any_but(topology_sibling_cpumask(cpu), cpu);
> + if (target >= nr_cpu_ids)
> + target = cpumask_any_but(topology_cluster_cpumask(cpu), cpu);
> + if (target >= nr_cpu_ids)
> + target = cpumask_any_but(topology_die_cpumask(cpu), cpu);
> + if (target >= nr_cpu_ids)
> + target = cpumask_any_but(topology_core_cpumask(cpu), cpu);
> + cmci_orphaned_target = target;
> for (i = 0; i < banks; i++)
> __cmci_disable_bank(i);
> + if (target < nr_cpu_ids)
> + bitmap_andnot(cmci_orphaned_banks, cmci_orphaned_banks,
> + per_cpu(mce_banks_owned, target), MAX_NR_BANKS);
[Severity: High]
Should the outward peer search in cmci_clear() also check
cpu_coregroup_mask(cpu) (or cpu_llc_shared_mask(cpu)) between
topology_cluster_cpumask(cpu) and topology_die_cpumask(cpu)?
In arch/x86/kernel/smpboot.c:set_cpu_sibling_map(), x86 populates
cpu_llc_shared_mask as a distinct topology level between
cpu_l2c_shared_mask (topology_cluster_cpumask) and topology_die_cpumask:
if ((i == cpu) || (has_smt && match_smt(c, o)))
link_mask(topology_sibling_cpumask, cpu, i);
if ((i == cpu) || (has_mp && match_llc(c, o)))
link_mask(cpu_llc_shared_mask, cpu, i);
if ((i == cpu) || (has_mp && match_l2c(c, o)))
link_mask(cpu_l2c_shared_mask, cpu, i);
if ((i == cpu) || (has_mp && match_die(c, o)))
link_mask(topology_die_cpumask, cpu, i);
On processors where cpu_coregroup_mask(cpu) is narrower than
topology_die_cpumask(cpu) (for example, processors that enumerate tiles via
CPUID leaf 0x1f tile domain or leaf 0x4 L3 cache sharing rather than die
domain, such as Meteor Lake and Arrow Lake where compute tile cores and SoC
tile LP E-cores have distinct llc_id values while sharing die_id, or Xeon
systems in SNC mode), offlining the last online CPU of an L2 cluster while
other CPUs in the same LLC/tile remain online will skip directly to
topology_die_cpumask(cpu).
If cpumask_any_but(topology_die_cpumask(cpu), cpu) picks a target on a
different LLC/tile, could an MCA bank scoped to the offlined CPU's LLC/tile
either be masked out of cmci_orphaned_banks by bitmap_andnot() (because the
remote-tile target owns its own tile's instance of that bank index) or fail
to be claimed by the remote target in cmci_rediscover(), leaving the bank
with CMCI disabled and unpolled while online peers in cpu_coregroup_mask(cpu)
are never probed?
> + else
> + bitmap_zero(cmci_orphaned_banks, MAX_NR_BANKS);
> raw_spin_unlock_irqrestore(&cmci_discover_lock, flags);
> }
>
> @@ -360,15 +390,38 @@ static void cmci_rediscover_work_func(void *arg)
> cmci_discover(banks);
> }
>
> -/* After a CPU went down cycle through all the others and rediscover */
> +/*
> + * After a CPU went down, rediscover orphaned shared banks on a single
> + * topology peer (SMT sibling, L2 cluster peer, die peer, or package peer)
> + * selected in cmci_clear(). Core-private banks whose core is now completely
> + * offline cannot be claimed by any other core, so probing more than one
> + * peer is redundant.
> + */
> void cmci_rediscover(void)
> {
> + unsigned int target;
> + unsigned long flags;
> + bool orphaned;
> int banks;
>
> if (!cmci_supported(&banks))
> return;
>
> - on_each_cpu(cmci_rediscover_work_func, NULL, 1);
> + raw_spin_lock_irqsave(&cmci_discover_lock, flags);
> + orphaned = !bitmap_empty(cmci_orphaned_banks, MAX_NR_BANKS);
> + target = cmci_orphaned_target;
> + raw_spin_unlock_irqrestore(&cmci_discover_lock, flags);
> +
> + if (!orphaned)
> + return;
> +
> + if (target < nr_cpu_ids && cpu_online(target))
> + smp_call_function_single(target, cmci_rediscover_work_func,
> + NULL, 1);
> +
> + raw_spin_lock_irqsave(&cmci_discover_lock, flags);
> + bitmap_zero(cmci_orphaned_banks, MAX_NR_BANKS);
> + raw_spin_unlock_irqrestore(&cmci_discover_lock, flags);
> }
[Severity: Medium]
Can probing only a single target CPU in cmci_rediscover() leave shared MCA
banks unclaimed on hybrid processors where CPUs on the same die or package
have different MCA bank counts or per-bank CMCI capabilities?
In cmci_rediscover_work_func(), cmci_supported(&banks) re-reads
MSR_IA32_MCG_CAP on the target CPU because CPUs do not necessarily all have
the same bank count:
/* Recheck banks in case CPUs don't all have the same */
if (cmci_supported(&banks))
cmci_discover(banks);
On hybrid systems (such as Alder Lake, Raptor Lake, Meteor Lake, or Arrow
Lake), P-cores and E-cores share topology_die_cpumask(cpu) and
topology_core_cpumask(cpu) while exposing different bank counts or bank
layouts. When the last thread of a P-core goes offline through
mce_cpu_pre_down() -> mce_disable_cpu() -> cmci_clear() and
mce_cpu_dead() -> cmci_rediscover(), cpumask_any_but() on the die or package
mask can select an E-core with a smaller bank count as cmci_orphaned_target
even when another P-core is still online.
When that happens, cmci_discover(banks) on target only iterates up to target's
bank count, and cmci_rediscover() then unconditionally clears
cmci_orphaned_banks with bitmap_zero() without falling back to other online
CPUs if unclaimed bits remain. Since other CPUs sharing those higher-numbered
banks already cleared them from their per-CPU mce_poll_banks bitmaps in
cmci_skip_bank() during initial discovery, wouldn't those shared banks remain
both unowned for CMCI and unpolled?
титься
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261019011446.834487-1-pasha.tatashin@soleen.com?part=3
next prev parent reply other threads:[~2026-10-20 1:15 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-19 1:14 [PATCH v2 0/8] x86, sched, mm: Speed up CPU hotplug on large systems Pasha Tatashin
2026-10-19 1:14 ` [PATCH v2 1/8] x86/realmode: Remove unnecessary WBINVD from AP startup trampoline Pasha Tatashin
2026-10-20 1:15 ` sashiko-bot
2026-10-19 1:14 ` [PATCH v2 2/8] x86/smp: Remove unnecessary WBINVD from mwait_play_dead() Pasha Tatashin
2026-10-20 1:15 ` sashiko-bot
2026-10-19 1:14 ` [PATCH v2 3/8] x86/mce/intel: Bound cmci_rediscover() to a single topology peer Pasha Tatashin
2026-10-20 1:15 ` sashiko-bot [this message]
2026-10-19 1:14 ` [PATCH v2 4/8] x86/cacheinfo, mtrr: Skip stop_machine rendezvous in cache_ap_online() when MTRRs match Pasha Tatashin
2026-10-20 1:15 ` sashiko-bot
2026-10-19 1:14 ` [PATCH v2 5/8] sched/topology: Avoid redundant O(N^3) group capacity walks and unused allocations in build_sched_domains() Pasha Tatashin
2026-10-20 1:15 ` sashiko-bot
2026-10-19 1:14 ` [PATCH v2 6/8] sched/deadline, topology: Avoid O(N^2) dl_server bandwidth walks during root_domain rebuilds Pasha Tatashin
2026-10-20 1:15 ` sashiko-bot
2026-10-19 1:14 ` [PATCH v2 7/8] sched/topology: Avoid redundant percpu allocations and bitmap walks in build_sched_domains() Pasha Tatashin
2026-10-20 1:15 ` sashiko-bot
2026-10-19 1:14 ` [PATCH v2 8/8] mm/vmstat: Avoid redundant per-CPU stat_threshold writes in refresh_zone_stat_thresholds() Pasha Tatashin
2026-10-20 1:16 ` sashiko-bot
2026-10-19 4:14 ` [PATCH v2 0/8] x86, sched, mm: Speed up CPU hotplug on large systems Borislav Petkov
2026-10-19 18:22 ` Luck, Tony
2026-10-19 19:11 ` Pasha Tatashin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-178404@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=blum@kernel.org \
--cc=bp@alien8.de \
--cc=bsegall@google.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=dietmar.eggemann@arm.com \
--cc=dmatlack@google.com \
--cc=gmonaco@redhat.com \
--cc=graf@amazon.com \
--cc=hannes@cmpxchg.org \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=jpoimboe@kernel.org \
--cc=juri.lelli@redhat.com \
--cc=kees@kernel.org \
--cc=kexec@lists.infradead.org \
--cc=kprateek.nayak@amd.com \
--cc=liam@infradead.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=longman@redhat.com \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=mkoutny@suse.com \
--cc=nik.borisov@suse.com \
--cc=pasha.tatashin@soleen.com \
--cc=peterz@infradead.org \
--cc=pratyush@kernel.org \
--cc=ridong.chen@linux.dev \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=seanjc@google.com \
--cc=surenb@google.com \
--cc=tglx@kernel.org \
--cc=tim.c.chen@linux.intel.com \
--cc=tj@kernel.org \
--cc=tony.luck@intel.com \
--cc=vbabka@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=vinicius.gomes@intel.com \
--cc=vschneid@redhat.com \
--cc=x86@kernel.org \
--cc=zhangguopeng@kylinos.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox