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: [RFC][PATCH v2 02/11] stop_machine: Accumulate error code rather than overwrite
Date: Tue, 31 Mar 2026 01:42:40 +0000 [thread overview]
Message-ID: <20260331014251.86353-3-chang.seok.bae@intel.com> (raw)
In-Reply-To: <20260331014251.86353-1-chang.seok.bae@intel.com>
cpu_stopper_thread() invokes a stop function and collects its error code
in struct cpu_stop_done. In the multi stop-machine case, it is shared
data, but currently an arbitrary error is recorded as overwriting.
With different errors, accumulating error code instead can distinguish a
multi-error condition as bits are cumulatively set.
Convert the error recoding to accumulate return values.
Suggested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Link: https://lore.kernel.org/lkml/20260304163335.GDaahe3wdnqxSC2yfw@fat_crate.local
---
V1 -> V2: New patch
While tried to explain its benefit here, I considered this change
deserves more discussions to ensure its impact, so RFC.
---
include/linux/stop_machine.h | 12 ++++++------
kernel/stop_machine.c | 10 +++++-----
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/include/linux/stop_machine.h b/include/linux/stop_machine.h
index c753dd53e79d..2f986555113a 100644
--- a/include/linux/stop_machine.h
+++ b/include/linux/stop_machine.h
@@ -124,9 +124,9 @@ static inline void print_stop_info(const char *log_lvl, struct task_struct *task
* the possibility of blocking in cpus_read_lock() means that the caller
* cannot usefully rely on this serialization.
*
- * Return: 0 if all invocations of @fn return zero. Otherwise, the
- * value returned by an arbitrarily chosen member of the set of calls to
- * @fn that returned non-zero.
+ * Return: 0 if all invocations of @fn return zero. Otherwise, an
+ * accumulated return value from all invocation of @fn that returned
+ * non-zero.
*/
int stop_machine(cpu_stop_fn_t fn, void *data, const struct cpumask *cpus);
@@ -154,9 +154,9 @@ int stop_machine_cpuslocked(cpu_stop_fn_t fn, void *data, const struct cpumask *
*
* Context: Must be called from within a cpus_read_lock() protected region.
*
- * Return: 0 if all invocations of @fn return zero. Otherwise, the
- * value returned by an arbitrarily chosen member of the set of calls to
- * @fn that returned non-zero.
+ * Return: 0 if all invocations of @fn return zero. Otherwise, an
+ * accumulated return value from all invocation of @fn that returned
+ * non-zero.
*/
int stop_core_cpuslocked(unsigned int cpu, cpu_stop_fn_t fn, void *data);
diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
index 822cf56fdc81..15268f1207e9 100644
--- a/kernel/stop_machine.c
+++ b/kernel/stop_machine.c
@@ -459,7 +459,7 @@ static int __stop_cpus(const struct cpumask *cpumask,
* RETURNS:
* -ENOENT if @fn(@arg) was not executed at all because all cpus in
* @cpumask were offline; otherwise, 0 if all executions of @fn
- * returned 0, any non zero return value if any returned non zero.
+ * returned 0, the accumulated value of all non-zero @fn returns.
*/
static int stop_cpus(const struct cpumask *cpumask, cpu_stop_fn_t fn, void *arg)
{
@@ -512,7 +512,7 @@ static void cpu_stopper_thread(unsigned int cpu)
ret = fn(arg);
if (done) {
if (ret)
- done->ret = ret;
+ done->ret |= ret;
cpu_stop_signal_done(done);
}
preempt_count_dec();
@@ -674,8 +674,8 @@ EXPORT_SYMBOL_GPL(stop_core_cpuslocked);
* Local CPU is inactive. Temporarily stops all active CPUs.
*
* RETURNS:
- * 0 if all executions of @fn returned 0, any non zero return value if any
- * returned non zero.
+ * 0 if all executions of @fn returned 0, otherwise the accumulated value
+ * of all non-zero @fn returns.
*/
int stop_machine_from_inactive_cpu(cpu_stop_fn_t fn, void *data,
const struct cpumask *cpus)
@@ -705,5 +705,5 @@ int stop_machine_from_inactive_cpu(cpu_stop_fn_t fn, void *data,
cpu_relax();
mutex_unlock(&stop_cpus_mutex);
- return ret ?: done.ret;
+ return ret | done.ret;
}
--
2.51.0
next prev parent 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 ` [PATCH v2 01/11] stop_machine: Clarify @cpus == NULL semantics Chang S. Bae
2026-07-23 4:34 ` Borislav Petkov
2026-03-31 1:42 ` Chang S. Bae [this message]
2026-08-09 2:04 ` [RFC][PATCH v2 02/11] stop_machine: Accumulate error code rather than overwrite 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-3-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.