Messages in this thread | | | Date | Wed, 2 Aug 2023 15:24:18 +0100 | Subject | Re: [PATCH v6] arm64: sdei: abort running SDEI handlers during crash | From | James Morse <> |
| |
Hi Scott,
On 27/06/2023 01:29, D Scott Phillips wrote: > Interrupts are blocked in SDEI context, per the SDEI spec: "The client > interrupts cannot preempt the event handler." If we crashed in the SDEI > handler-running context (as with ACPI's AGDI) then we need to clean up the > SDEI state before proceeding to the crash kernel so that the crash kernel > can have working interrupts. > > Track the active SDEI handler per-cpu so that we can COMPLETE_AND_RESUME > the handler, discarding the interrupted context.
I still argue this is a firmware bug. That preempt text was supposed to mean "PSTATE.DAIF get set", the whole "GIC abstraction" thing got shoehorned in much later.
But I agree we need to work around it in linux.
> diff --git a/drivers/firmware/arm_sdei.c b/drivers/firmware/arm_sdei.c > index f9040bd61081..285fe7ad490d 100644 > --- a/drivers/firmware/arm_sdei.c > +++ b/drivers/firmware/arm_sdei.c > @@ -1095,3 +1095,22 @@ int sdei_event_handler(struct pt_regs *regs, > return err; > } > NOKPROBE_SYMBOL(sdei_event_handler); > + > +void sdei_handler_abort(void) > +{ > + /* > + * If the crash happened in an SDEI event handler then we need to > + * finish the handler with the firmware so that we can have working > + * interrupts in the crash kernel. > + */ > + if (__this_cpu_read(sdei_active_critical_event)) { > + pr_warn("still in SDEI critical event context, attempting to finish handler.\n"); > + __sdei_handler_abort(); > + __this_cpu_write(sdei_active_critical_event, NULL); > + } > + if (__this_cpu_read(sdei_active_normal_event)) { > + pr_warn("still in SDEI normal event context, attempting to finish handler.\n"); > + __sdei_handler_abort(); > + __this_cpu_write(sdei_active_normal_event, NULL); > + } > +}
I'm not sure why this moved out to drivers/firmware when the only caller is the arch code, but it doesn't matter...
Reviewed-by: James Morse <james.morse@arm.com>
Thanks,
James
| |