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, chang.seok.bae@intel.com
Subject: [PATCH v2 01/11] stop_machine: Clarify @cpus == NULL semantics
Date: Tue, 31 Mar 2026 01:42:39 +0000	[thread overview]
Message-ID: <20260331014251.86353-2-chang.seok.bae@intel.com> (raw)
In-Reply-To: <20260331014251.86353-1-chang.seok.bae@intel.com>

The stop-machine API description currently mentions that @cpus == NULL
means running on "each cpu_online_mask". Previously, it was described as
"any cpu_online_mask" before commit:

  fc6f89dc707 ("stop_machine: Improve kernel-doc function-header comments")

In fact, multi_cpu_stop() selects the first CPU in cpu_online_mask when
@cpus is NULL. Right now cpumask_any() is defined as cpumask_first(). So
the previous description was closer but apparently it was not clear
enough either.

Fix those comments for clarity.

Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
---
V1 -> V2: New patch

Considering stop_machine_nmi_cpuslocked() and its another cpumask, I
could realize this nullptr implication is not clear enough. Then, it
ended up with this fix.

I also considered just saying CPU0, but still 'cpumask_first(cpu_online_mask)'
are there. So, leave it like that, instead of converting them
aggressively.
---
 include/linux/stop_machine.h | 6 ++++--
 kernel/stop_machine.c        | 4 +++-
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/include/linux/stop_machine.h b/include/linux/stop_machine.h
index 72820503514c..c753dd53e79d 100644
--- a/include/linux/stop_machine.h
+++ b/include/linux/stop_machine.h
@@ -99,7 +99,8 @@ static inline void print_stop_info(const char *log_lvl, struct task_struct *task
  * stop_machine: freeze the machine on all CPUs and run this function
  * @fn: the function to run
  * @data: the data ptr to pass to @fn()
- * @cpus: the cpus to run @fn() on (NULL = run on each online CPU)
+ * @cpus: the CPUs to run @fn() on. If NULL, @fn() runs on a single
+ *        (arbitrary) CPU from cpu_online_mask.
  *
  * Description: This causes a thread to be scheduled on every CPU, which
  * will run with interrupts disabled.  Each CPU specified by @cpus will
@@ -133,7 +134,8 @@ int stop_machine(cpu_stop_fn_t fn, void *data, const struct cpumask *cpus);
  * stop_machine_cpuslocked: freeze the machine on all CPUs and run this function
  * @fn: the function to run
  * @data: the data ptr to pass to @fn()
- * @cpus: the cpus to run @fn() on (NULL = run on each online CPU)
+ * @cpus: the CPUs to run @fn() on. If NULL, @fn() runs on a single
+ *        (arbitrary) CPU from cpu_online_mask.
  *
  * Same as above.  Avoids nested calls to cpus_read_lock().
  *
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 3fe6b0c99f3d..822cf56fdc81 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -655,9 +655,11 @@ EXPORT_SYMBOL_GPL(stop_core_cpuslocked);
 
 /**
  * stop_machine_from_inactive_cpu - stop_machine() from inactive CPU
+ *
  * @fn: the function to run
  * @data: the data ptr for the @fn()
- * @cpus: the cpus to run the @fn() on (NULL = any online cpu)
+ * @cpus: the CPUs to run the @fn() on. If NULL, @fn() runs on a single
+ *        (arbitrary) CPU from cpu_online_mask.
  *
  * This is identical to stop_machine() but can be called from a CPU which
  * is not active.  The local CPU is in the process of hotplug (so no other
-- 
2.51.0


  reply	other threads:[~2026-03-31  2:14 UTC|newest]

Thread overview: 18+ 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 ` Chang S. Bae [this message]
2026-07-23  4:34   ` [PATCH v2 01/11] stop_machine: Clarify @cpus == NULL semantics Borislav Petkov
2026-03-31  1:42 ` [RFC][PATCH v2 02/11] stop_machine: Accumulate error code rather than overwrite Chang S. Bae
2026-08-09  2:04   ` Borislav Petkov
2026-08-11  6:02     ` 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
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
2026-08-09  2:05 ` [PATCH v2 00/11] x86/microcode: Refactor NMI-based rendezvous mechanism to stop-machine Borislav Petkov
2026-08-11  6:02   ` 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=20260331014251.86353-2-chang.seok.bae@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.