[PATCH 4/4] arm64: route crash_smp_send_stop() last resort through SDEI

[Kiryl Shutsemau]

On Fri, Jun 05, 2026 at 01:42:57PM -0700, Doug Anderson wrote:
> > +       sdei_nmi_crash_smp_send_stop();
> 
> It feels weird to me that you're adding SDEI for "crash stop" but not
> for regular "stop". It feels like you should modify smp_send_stop() to
> fall back to SDEI if sending the NMI failed, instead of adding this
> separate path.

Fair. A wedged CPU ignores the reboot-path stop just the same, and the
escalation logic already lives in smp.c, so I'll restructure in v2.

One thing to sort out there: this patch parks the stopped CPU inside
its SDEI handler without completing the event, which is fine for the
crash case (nothing expects the CPU back before reset), but a generic
stop path probably wants SDEI_EVENT_COMPLETE_AND_RESUME into a parking
stub instead, so that e.g. a regular kexec can bring all CPUs back up
in the new kernel. I'll look into that as part of the rework.

> > +               cpu_park_loop();
> > +               /* unreachable */
> 
> Any chance we could avoid duplicating stuff from ipi_cpu_crash_stop()?

Yes -- falls out of the above. I will look into this.

Maybe pull the save/offline/park body into a shared helper that both the
IPI handler and the SDEI handler call.

> > +bool sdei_nmi_crash_smp_send_stop(void)
> > +{
> > +       unsigned int this_cpu, cpu, remaining;
> > +       unsigned long timeout;
> > +       cpumask_t mask;
> 
> The above will probably get you a yell. Putting "cpumask_t" on the
> stack is a no-no since it can be quite large under certain CONFIG
> options. This is why it's nearly always defined as "static".

Doh! Will make it static in v2 -- safe here since the path is serialized
by the crash_stop guard.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov