Messages in this thread | | | Date | Wed, 25 Apr 2018 19:15:57 +0200 | From | Borislav Petkov <> | Subject | Re: [RFC PATCH v2 3/4] acpi: apei: Do not panic() when correctable errors are marked as fatal. |
| |
On Wed, Apr 25, 2018 at 10:00:53AM -0500, Alex G. wrote: > Firmware-first.
Ok, my guess was right.
> We could probably use more of the native AER print functions, but that's > beyond the scope of this patch.
No no, this does not belong in this patchset.
> Like the exact thing that this patch series implements? :)
Exact thing? I don't think so.
No, your patchset is grafting some funky and questionable side-handler which gets to see the PCIe errors first, out-of-line and then it practically downgrades their severity outside of the error processing flow.
What I've been telling you to do is to extend ghes_severity() to give the lower than PANIC severity for CPER_SEC_PCIE errors first so that the machine doesn't panic from them anymore and those PCIe errors get processed in the normal error processing path down through ghes_do_proc() and then land in ghes_handle_aer(). No adhoc ->handle_irqsafe thing - just the normal straightforward error processing path.
There, in ghes_handle_aer(), you do the check whether the device is still there - i.e., you try to apply some heuristics to detect the error type and why the system is complaining - you maybe even check whether the NVMe device is still there - and *then* you do the proper recovery action.
And you document for the future people looking at this code *why* you're doing this.
-- Regards/Gruss, Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
| |