* [PATCH] panic: make force_cpu redirect work from an NMI
@ 2026-07-07 20:59 Bradley Morgan
2026-07-08 12:44 ` Petr Mladek
0 siblings, 1 reply; 2+ messages in thread
From: Bradley Morgan @ 2026-07-07 20:59 UTC (permalink / raw)
To: akpm; +Cc: pmladek, feng.tang, linux-kernel, include
nmi_panic sets panic_cpu first. Bail only on a different
owner, and hand panic_cpu to the target after the IPI.
Found by sashiko [1].
[1] https://sashiko.dev/#/patchset/20260707183253.9793-1-include@grrlz.net
Signed-off-by: Bradley Morgan <include@grrlz.net>
---
kernel/panic.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/kernel/panic.c b/kernel/panic.c
index e46c37b39c40..95ebf2bb0bf9 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -396,8 +396,8 @@ static bool panic_try_force_cpu(const char *fmt, va_list args)
return false;
}
- /* Another panic already in progress */
- if (panic_in_progress())
+ /* Bail only if a different CPU is already handling it. */
+ if (panic_in_progress() && atomic_read(&panic_cpu) != this_cpu)
return false;
/* Which CPU won the race? */
@@ -440,6 +440,9 @@ static bool panic_try_force_cpu(const char *fmt, va_list args)
return false;
}
+ /* Hand panic_cpu to the target so it wins its own panic_try_start. */
+ atomic_set(&panic_cpu, panic_force_cpu);
+
/* IPI/NMI sent, this CPU should stop */
return true;
}
--
2.53.0
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] panic: make force_cpu redirect work from an NMI
2026-07-07 20:59 [PATCH] panic: make force_cpu redirect work from an NMI Bradley Morgan
@ 2026-07-08 12:44 ` Petr Mladek
0 siblings, 0 replies; 2+ messages in thread
From: Petr Mladek @ 2026-07-08 12:44 UTC (permalink / raw)
To: Bradley Morgan
Cc: akpm, feng.tang, Steven Rostedt, Peter Zijlstra, Thomas Gleixner,
linux-kernel
Adding more people into Cc.
I wonder if smp_call_function_single_async() can be called
safely from NMI. Maybe, we should skip the redirection
completely in this case.
On Tue 2026-07-07 20:59:21, Bradley Morgan wrote:
> nmi_panic sets panic_cpu first. Bail only on a different
> owner, and hand panic_cpu to the target after the IPI.
This is quite cryptic.
Who should bail?
What is target?
What IPI?
Please, do more descriptive commit messages and better
explain the problematic situation.
> Found by sashiko [1].
Better to use:
Reported-by: Sashiko <sashiko-bot@kernel.org>
> [1]
> https://sashiko.dev/#/patchset/20260707183253.9793-1-include@grrlz.net
Closes: https://sashiko.dev/#/patchset/20260707183253.9793-1-include@grrlz.net
> Signed-off-by: Bradley Morgan <include@grrlz.net>
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -396,8 +396,8 @@ static bool panic_try_force_cpu(const char *fmt, va_list args)
> return false;
> }
>
> - /* Another panic already in progress */
> - if (panic_in_progress())
> + /* Bail only if a different CPU is already handling it. */
> + if (panic_in_progress() && atomic_read(&panic_cpu) != this_cpu)
There already exist panic_on_other_cpu()...
> return false;
This looks strange. "return false" means that vpanic() will
continue with panic. I would expect that this CPU should end up
offline.
It would actually work because vpanic() continues with:
if (panic_try_start()) {
/* go ahead */
} else if (panic_on_other_cpu())
panic_smp_self_stop();
And panic_try_start() would obviously fail while panic_on_other_cpu()
succeed.
But still, it would be more straightforward to do here:
/* Stop this CPU when the panic is already proceed elsewhere. */
if (panic_on_other_cpu())
return true;
> - /* Another panic already in progress */
> - if (panic_in_progress())
> + /* Bail only if a different CPU is already handling it. */
> + if (panic_in_progress() && atomic_read(&panic_cpu) != this_cpu)
>
> /* Which CPU won the race? */
> @@ -440,6 +440,9 @@ static bool panic_try_force_cpu(const char *fmt, va_list args)
> return false;
> }
>
> + /* Hand panic_cpu to the target so it wins its own panic_try_start. */
> + atomic_set(&panic_cpu, panic_force_cpu);
As I already mentioned, this is too late. The panic_force_cpu might
already be offline because it called panic_try_start() earlier it
it failed.
The main question is whether we could safely call
smp_call_function_single_async() from NMI at all.
If not then we will need to proceed panic() on this CPU.
If yes then we need to fix this in nmi_panic(). It should
call panic_try_force_cpu() first. It should call panic_try_start()
only when panic_try_force_cpu() returns false, like when
it did not forced another CPU.
r
> /* IPI/NMI sent, this CPU should stop */
> return true;
Best Regards,
Petr
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-07-08 12:44 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-07 20:59 [PATCH] panic: make force_cpu redirect work from an NMI Bradley Morgan
2026-07-08 12:44 ` Petr Mladek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox