[PATCH v2] ACPI: APEI: Handle repeated SEA error storms

[Rafael J. Wysocki (Intel)]

On Fri, Aug 7, 2026 at 6:36 PM Luck, Tony <tony.luck at intel.com> wrote:
>
> > a gentle ping on this.
> > All comments are welcomed!
>
> >> I think, but I'm not sure, that you are addressing call from here. By
> >> returning -ECANCELLED this code skips the irq_work_queue() call and
> >> returns -ENOENT (instead of zero).
> >>
> >> ghes_in_nmi_spool_from_list()
> >>
> >> Effect here is more complex. Depends on whether there are multiple
> >> ghes entries on the rcu_list. If there was just one, and you return
> >> -ECANCELLED, then irq_work_queue() is skipped. But if there are multiple
> >> entries on the list and at least one of them gets a zero return from
> >> ghes_in_nmi_queue_one_entry() then irq_work_queue() is called.
> > Hi Luck Tony,
> >
> > Thanks for the comments.
> >
> > This fix is only for the call to ghes_in_nmi_spool_from_list() from ghes_notify_sea() on
> > ARM platforms (ACPI_HEST_NOTIFY_SEA); other paths are unchanged.
> >
> > If multiple SEA errors occur simultaneously, multiple entries in ghes_sea are active
> > and one of them returns 0, then -ECANCELED is discarded, but the unhandled
> > SEA will simply trigger again and re-enter the SEA handler to be processed.
> >
> > The worst case is when multiple valid SEA entries persist within the 10-second
> > ghes_estatus_cached() window — the fact is that a great many SEA errors are
> > produced, which actually constitutes a real SEA storm, not one triggered by a single
> > SEA, and in this situation not delivering SIGBUS in time to kill the process is acceptable.
>
> I think this is OK.
>
> Reviewed-by: Tony Luck <tony.luck at intel.com>

Applied as 7.3 material, thanks!