All of lore.kernel.org
 help / color / mirror / Atom feed
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,
	thorsten.blum@linux.dev, tony.luck@intel.com, david@kernel.org,
	mingo@redhat.com, akpm@linux-foundation.org, seanjc@google.com,
	ljs@kernel.org, zhangguopeng@kylinos.cn,
	dietmar.eggemann@arm.com, mhocko@suse.com,
	vinicius.gomes@intel.com, tj@kernel.org, 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,
	longman@redhat.com, bsegall@google.com
Cc: hannes@cmpxchg.org, mkoutny@suse.com
Subject: Re: [PATCH v1 2/8] x86/smp: Remove unnecessary WBINVD from mwait_play_dead()
Date: Thu, 15 Oct 2026 15:44:44 +0000	[thread overview]
Message-ID: <sashiko-outbox-173092@kernel.org> (raw)
In-Reply-To: <20261015153331.1872641-3-pasha.tatashin@soleen.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] x86/smp: memory corruption during suspend if package offlined at runtime
- [High] x86/smp: offline CPUs miss wbinvd_on_all_cpus() flush causing data corruption
--

commit 2579aa1d01a44c8d96bb166fd2ce0dff4493a42a
Author: Pasha Tatashin <pasha.tatashin@soleen.com>

x86/smp: Remove unnecessary WBINVD from mwait_play_dead()

The commit aims to avoid time-consuming WBINVDs during runtime CPU offlining
by only executing it when cpuhp_tasks_frozen is set (i.e. system sleep).

> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index ba01a9e919b78..60a781dac9991 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
[ ... ]
> @@ -1426,15 +1422,21 @@ void __noreturn mwait_play_dead(unsigned int eax_hint)
>  	md->status = CPUDEAD_MWAIT_WAIT;
>  	md->control = CPUDEAD_MWAIT_WAIT;
>  
> -	wbinvd();
> +	/*
> +	 * MWAIT C-states keep the caches coherent, so runtime CPU offline
> +	 * does not need to flush them. System sleep, however, may remove
> +	 * power from this package's caches while all of its CPUs are
> +	 * offline, and the flush done by the boot CPU before entering the
> +	 * sleep state only covers the boot CPU's own package.
> +	 */
> +	if (cpuhp_tasks_frozen)
> +		wbinvd();

[Severity: Critical]
Could this result in memory corruption during a system suspend if an entire
package is offlined at runtime prior to the suspend?

If a package is fully offlined at runtime (so cpuhp_tasks_frozen is false),
its CPUs enter MWAIT with dirty caches. If the system later suspends,
freeze_secondary_cpus() skips CPUs that are already offline:

kernel/cpu.c:freeze_secondary_cpus() {
	...
	for (cpu = nr_cpu_ids - 1; cpu >= 0; cpu--) {
		if (!cpu_online(cpu) || cpu == primary)
			continue;
	...
}

Because these CPUs are skipped, they never awaken to check cpuhp_tasks_frozen
and perform the flush. Since the sleep-entry cache flush on the boot CPU
only covers its own package, won't the dirty cache lines of the un-flushed,
offlined package be permanently lost when power is removed?

[Severity: High]
Does skipping the flush during runtime offline break the system-wide cache
flush guarantees of wbinvd_on_all_cpus()?

If a package is completely offlined at runtime and retains dirty cache lines
in its LLC, wbinvd_on_all_cpus() will miss them entirely because it only
targets online CPUs:

arch/x86/lib/cache-smp.c:wbinvd_on_all_cpus() {
	on_each_cpu(__wbinvd, NULL, 1);
}

If a system-wide non-coherent operation is later triggered (such as mapping
memory as Uncacheable or persisting PMEM), the missing flush could lead to
data corruption or Machine Check Exceptions from dirty line evictions.

Furthermore, during Kexec, offline CPUs are kicked out of MWAIT:

arch/x86/kernel/smpboot.c:smp_kick_mwait_play_dead() {
	...
	for_each_cpu_andnot(cpu, cpu_present_mask, cpu_online_mask) {
		...
		WRITE_ONCE(md->control, newstate);
	...
}

Will this cause the offlined CPUs to carry unflushed dirty cache lines into
the new kernel's execution context?

>  
>  	while (1) {
>  		/*
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015153331.1872641-1-pasha.tatashin@soleen.com?part=2


  reply	other threads:[~2026-10-15 15:44 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 15:33 [PATCH v1 0/8] x86, sched, mm: Speed up CPU hotplug on large systems Pasha Tatashin
2026-10-15 15:33 ` [PATCH v1 1/8] x86/realmode: Remove unnecessary WBINVD from AP startup trampoline Pasha Tatashin
2026-10-15 15:41   ` sashiko-bot
2026-10-15 15:33 ` [PATCH v1 2/8] x86/smp: Remove unnecessary WBINVD from mwait_play_dead() Pasha Tatashin
2026-10-15 15:44   ` sashiko-bot [this message]
2026-10-15 16:26     ` Pasha Tatashin
2026-10-15 15:33 ` [PATCH v1 3/8] x86/mce/intel: Bound cmci_rediscover() to a single topology peer Pasha Tatashin
2026-10-15 15:51   ` sashiko-bot
2026-10-15 15:33 ` [PATCH v1 4/8] x86/cacheinfo, mtrr: Skip stop_machine rendezvous in cache_ap_online() when MTRRs match Pasha Tatashin
2026-10-15 15:45   ` sashiko-bot
2026-10-15 15:33 ` [PATCH v1 5/8] sched/topology: Avoid redundant O(N^3) group capacity walks and unused allocations in build_sched_domains() Pasha Tatashin
2026-10-15 15:43   ` sashiko-bot
2026-10-15 15:33 ` [PATCH v1 6/8] sched/deadline, topology: Avoid O(N^2) dl_server bandwidth walks during root_domain rebuilds Pasha Tatashin
2026-10-15 15:57   ` sashiko-bot
2026-10-15 20:43     ` Pasha Tatashin
2026-10-15 15:33 ` [PATCH v1 7/8] sched/topology: Avoid redundant percpu allocations and bitmap walks in build_sched_domains() Pasha Tatashin
2026-10-15 15:51   ` sashiko-bot
2026-10-15 23:17   ` Tim Chen
2026-10-15 15:33 ` [PATCH v1 8/8] mm/vmstat: Avoid redundant per-CPU stat_threshold writes in refresh_zone_stat_thresholds() Pasha Tatashin
2026-10-15 15:49   ` sashiko-bot
2026-10-15 21:33 ` [PATCH v1 0/8] x86, sched, mm: Speed up CPU hotplug on large systems Luck, Tony

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-173092@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=akpm@linux-foundation.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=juri.lelli@redhat.com \
    --cc=kees@kernel.org \
    --cc=kexec@lists.infradead.org \
    --cc=kprateek.nayak@amd.com \
    --cc=liam@infradead.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=thorsten.blum@linux.dev \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.