All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Chang S. Bae" <chang.seok.bae@intel.com>
To: <linux-kernel@vger.kernel.org>
Cc: <x86@kernel.org>, <tglx@kernel.org>, <mingo@redhat.com>,
	<bp@alien8.de>, <dave.hansen@linux.intel.com>,
	<peterz@infradead.org>, <david.kaplan@amd.com>
Subject: Re: [PATCH v2 04/11] stop_machine: Add NMI-based execution path
Date: Tue, 31 Mar 2026 19:57:12 -0700	[thread overview]
Message-ID: <7e7c9797-2f8b-4dde-b2f0-549a8816d8da@intel.com> (raw)
In-Reply-To: <20260331014251.86353-5-chang.seok.bae@intel.com>

[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

Like others, I also checked the review bot:

  https://sashiko.dev/#/patchset/20260331014251.86353-1-chang.seok.bae@intel.com

I thought all of comments could be converged in this patch. My take is 
below.

On 3/30/2026 6:42 PM, Chang S. Bae wrote:
> 
> +struct nmi_stop {
> +	struct multi_stop_data	*data;
> +	int			ret;
> +	bool			done;

The intention was to make it clear at the waiting loop. But ->data == 
NULL check can substitute it and a single variable looks to make it more 
robust and simple.

> +bool noinstr stop_machine_nmi_handler(void)
> +{
> +	struct multi_stop_data *msdata = raw_cpu_read(nmi_stop.data);
> +	unsigned int cpu = smp_processor_id();
> +	int ret;
> +
> +	if (!msdata || !cpumask_test_and_clear_cpu(cpu, msdata->nmi_cpus))
> +		return false;

smp_processor_id() and cpumask_test_and_clear_cpu() are wrappers that 
could include instrumentation, so not suitable here. Instead, 
raw_smp_processor_id() and arch_test_and_clear_bit() are inner functions.


> +	/* Ensure the handler went through before reading the result */
> +	if (!wait_for_nmi_handler())
> +		return -ETIMEDOUT;

On error exit, the stop_data pointer should be cleaned up as well before 
it is freed later.


Attached is the diff addressing them.

[-- Attachment #2: patch4.diff --]
[-- Type: text/plain, Size: 2107 bytes --]

diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 45ea62f1b2b5..5bd1105d1a11 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -730,7 +730,6 @@ int stop_machine_from_inactive_cpu(cpu_stop_fn_t fn, void *data,
 struct nmi_stop {
 	struct multi_stop_data	*data;
 	int			ret;
-	bool			done;
 };
 
 static DEFINE_PER_CPU(struct nmi_stop, nmi_stop);
@@ -743,10 +742,10 @@ static DEFINE_PER_CPU(struct nmi_stop, nmi_stop);
 bool noinstr stop_machine_nmi_handler(void)
 {
 	struct multi_stop_data *msdata = raw_cpu_read(nmi_stop.data);
-	unsigned int cpu = smp_processor_id();
+	unsigned int cpu = raw_smp_processor_id();
 	int ret;
 
-	if (!msdata || !cpumask_test_and_clear_cpu(cpu, msdata->nmi_cpus))
+	if (!msdata || !arch_test_and_clear_bit(cpu, cpumask_bits(msdata->nmi_cpus)))
 		return false;
 
 	/*
@@ -759,7 +758,6 @@ bool noinstr stop_machine_nmi_handler(void)
 	instrumentation_end();
 
 	raw_cpu_write(nmi_stop.ret,  ret);
-	raw_cpu_write(nmi_stop.done, true);
 	raw_cpu_write(nmi_stop.data, NULL);
 
 	return true;
@@ -770,10 +768,11 @@ static bool wait_for_nmi_handler(void)
 	/* Conservative timeout */
 	unsigned long timeout = USEC_PER_SEC;
 
-	while (!this_cpu_read(nmi_stop.done) && timeout--)
+	/* The handler clears up at the end */
+	while (this_cpu_read(nmi_stop.data) && timeout--)
 		udelay(1);
 
-	return this_cpu_read(nmi_stop.done);
+	return !this_cpu_read(nmi_stop.data);
 }
 
 static int nmi_stop_run(struct multi_stop_data *msdata)
@@ -783,12 +782,16 @@ static int nmi_stop_run(struct multi_stop_data *msdata)
 	 * self-NMI to execute the stop function from the NMI handler
 	 */
 	this_cpu_write(nmi_stop.data, msdata);
-	this_cpu_write(nmi_stop.done, false);
 	arch_send_self_nmi();
 
-	/* Ensure the handler went through before reading the result */
-	if (!wait_for_nmi_handler())
+	/*
+	 * Ensure the handler went through before reading the result.
+	 * Otherwise, make no stale state left behind.
+	 */
+	if (!wait_for_nmi_handler()) {
+		this_cpu_write(nmi_stop.data, NULL);
 		return -ETIMEDOUT;
+	}
 
 	return this_cpu_read(nmi_stop.ret);
 }


  reply	other threads:[~2026-04-01  2:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-31  1:42 [PATCH v2 00/11] x86/microcode: Refactor NMI-based rendezvous mechanism to stop-machine Chang S. Bae
2026-03-31  1:42 ` [PATCH v2 01/11] stop_machine: Clarify @cpus == NULL semantics Chang S. Bae
2026-03-31  1:42 ` [RFC][PATCH v2 02/11] stop_machine: Accumulate error code rather than overwrite Chang S. Bae
2026-03-31  1:42 ` [PATCH v2 03/11] stop_machine: Refactor multi-CPU stop glue code Chang S. Bae
2026-03-31  1:42 ` [PATCH v2 04/11] stop_machine: Add NMI-based execution path Chang S. Bae
2026-04-01  2:57   ` Chang S. Bae [this message]
2026-03-31  1:42 ` [PATCH v2 05/11] stop_machine: Introduce stop_machine_nmi_cpuslocked() Chang S. Bae
2026-03-31  1:42 ` [PATCH v2 06/11] x86/apic: Implement self-NMI support Chang S. Bae
2026-03-31  1:42 ` [PATCH v2 07/11] x86/nmi: Support NMI stop-machine handler Chang S. Bae
2026-03-31  1:42 ` [PATCH v2 08/11] x86/microcode: Distinguish NMI control path on stop-machine callback Chang S. Bae
2026-03-31  1:42 ` [PATCH v2 09/11] x86/microcode: Use stop-machine NMI facility Chang S. Bae
2026-03-31  1:42 ` [PATCH v2 10/11] x86/nmi: Simplify offline microcode handler invocation Chang S. Bae
2026-03-31  1:42 ` [PATCH v2 11/11] x86/microcode: Remove microcode_nmi_handler_enable Chang S. Bae

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=7e7c9797-2f8b-4dde-b2f0-549a8816d8da@intel.com \
    --to=chang.seok.bae@intel.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=david.kaplan@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    /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.