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