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

"Luck, Tony" <[email protected]> Fri, 7 Aug 2026 16:36:10 +0000
Newsgroups gmane.linux.kernel,gmane.linux.acpi.devel,gmane.linux.ports.arm.kernel
Message-ID <SJ1PR11MB6083D39FF213C8A03F4D3C42FCD12@SJ1PR11MB6083.namprd11.prod.outlook.com>
> 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 <[email protected]>

-Tony