FFS (firmware-first) handling through APEI seems to have developed a policy to panic() on any fatal errors. This policy is completely independent of the non-FFS case. It is also inconsistent with how the native error handlers, a number of which will recover the system from fatal errors. The purpose of this series is to obsolete this idiotic policy, with the motivation to enable identical handling of PCIe errors to native reporting. Rafael, this is copypaste from the previous patch series. I suspect you might have missed it last time, because you asked questions which were answered here. I've included it so you don't have to go digging old emails: " The purpose of these changes is to see if we can safely de-escalate the situation and notify the appropriate error handler. Since FFS reports errors through NMIs or other non-standard mechanism, we have to be just a little more careful with reporting the error. We're concerned with things, such as being able to cross the NMI/IRQ boundary, or being able to safely schedule work and notify the appropriate subsystem. Once the notification is sent, our job is done. I'm explicitly _NOT_ concerned with whether the error is handled or not, especially since such concern reduces to a call to __ghes_panic(). There are rare cases that prevent us from de-escalating to lesser contexts, such as uncorrectable memory errors in kernel. In these sort of cases, trying to leave the NMI might cause a triple fault. James Morse explained this very well when discussing v1 of this series. In and only in such cases, we are justified to panic(). Once the error is safely sent its merry way, it's really up to the error handler to panic() or continue. For example, aer_recover_queue() might for ungodly reasons fail. However, it's up to the AER code to decide whether failing to queue an error for handling is panic worthy. " Changes since v6: - Fixed silly compilation warning - Dropped concept of Changes since v5: - Removed zoological references from commit message Changes since v4: - Fix Freudian slip and use GHES_ instead of CPER_ enum - Rephrased comments to clarify what we don't care about Changes since v3: - Renamed ghes_severity to something more concrete - Reorganized code to make it look like more than just a rename - Remembered to remove last patch in the series Changes since v2: - Due to popular request, simple is chosen over flexible - Removed splitting of handlers into irq safe portion. - Change behavior only for PCIe errors Changes since v1: - Due to popular request, the panic() is left in the NMI handler - GHES AER handler is split into NMI and non-NMI portions - ghes_notify_nmi() does not panic on deferrable errors - The handlers are put in a mapping and given a common call signature Alexandru Gagniuc (3): acpi: apei: Rename GHES_SEV_PANIC to GHES_SEV_FATAL acpi: apei: Rename ghes_severity() to ghes_cper_severity() acpi: apei: Do not panic() on PCIe errors reported through GHES arch/x86/kernel/cpu/mcheck/mce-apei.c | 2 +- drivers/acpi/apei/ghes.c | 65 +++++++++++++++++++++++++++-------- drivers/edac/ghes_edac.c | 2 +- include/acpi/ghes.h | 2 +- 4 files changed, 54 insertions(+), 17 deletions(-) -- 2.14.3 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
