ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Subsystems (7)
RFC 1/1 ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform hardware errors (such as that from chipset). It works in so called "Firmware First" mode, that is, hardware errors are reported to firmware firstly, then reported to Linux by firmware. This way, some non-standard hardware error registers or non-standard hardware link can be checked by firmware to produce more valuable hardware error information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information from BIOS to Linux can be determined only in NMI, IRQ or timer handler, but general ioremap can not be used in atomic context, so a special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified via NMI, because printk is not NMI-safe. Will fix this via delay printing to IRQ context via irq_work or make printk NMI-safe.
--- arch/x86/kernel/acpi/boot.c | 1 arch/x86/kernel/dumpstack.c | 1 drivers/acpi/apei/ghes.c | 428 ++++++++++++++++++++++++++++++++++---------- kernel/panic.c | 1 lib/ioremap.c | 2 mm/vmalloc.c | 1 6 files changed, 345 insertions(+), 89 deletions(-)
arch/x86/kernel/acpi/boot.c +1 -0
@@ -504,6 +504,7 @@ int acpi_gsi_to_irq(u32 gsi, unsigned inreturn 0 ; } +EXPORT_SYMBOL_GPL (acpi_gsi_to_irq);int acpi_isa_irq_to_gsi (unsigned isa_irq,u32 *gsi) {
arch/x86/kernel/dumpstack.c +1 -0
@@ -240,6 +240,7 @@ unsigned __kprobes long oops_begin(void)bust_spinlocks (1 );return flags; } +EXPORT_SYMBOL_GPL (oops_begin);void __kprobes oops_end (unsigned long flags,struct pt_regs *regs,int signr) {
drivers/acpi/apei/ghes.c +339 -89
587 lines not on this page · raw message
kernel/panic.c +1 -0
@@ -34,6 +34,7 @@ static int pause_on_oops_flag;static DEFINE_SPINLOCK (pause_on_oops_lock);int panic_timeout; +EXPORT_SYMBOL_GPL (panic_timeout);ATOMIC_NOTIFIER_HEAD (panic_notifier_list);
lib/ioremap.c +2 -0
@@ -9,6 +9,7 @@#include <linux/mm.h> #include <linux/sched.h> #include <linux/io.h> +#include <linux/module.h> #include <asm/cacheflush.h> #include <asm/pgtable.h>
@@ -90,3 +91,4 @@ int ioremap_page_range(unsigned long addreturn err; } +EXPORT_SYMBOL_GPL (ioremap_page_range);
mm/vmalloc.c +1 -0
@@ -1175,6 +1175,7 @@ void unmap_kernel_range_noflush(unsigned {vunmap_page_range (addr, addr + size); } +EXPORT_SYMBOL_GPL (unmap_kernel_range_noflush);/** * unmap_kernel_range - unmap kernel VM area and flush cache and TLB
Luck, Tony
reviewerQuoted 10 lines
Because the memory area used to transfer hardware error information from BIOS to Linux can be determined only in NMI, IRQ or timer handler, but general ioremap can not be used in atomic context, so a special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified via NMI, because printk is not NMI-safe. Will fix this via delay printing to IRQ context via
irq_workor make printk NMI-safe.
Would it be possible to defer the "ioremap" to a work queue too? Then we wouldn't need the special versions of ioremap.
-Tony
Quoted 5 lines · Tony
Quoted 5 lines
Because the memory area used to transfer hardware error information from BIOS to Linux can be determined only in NMI, IRQ or timer handler, but general ioremap can not be used in atomic context, so a special version of atomic ioremap is implemented for that.
Quoted 8 lines
Quoted 5 lines
Known issue:
- Error information can not be printed for recoverable errors notified via NMI, because printk is not NMI-safe. Will fix this via delay printing to IRQ context via
irq_workor make printk NMI-safe.Would it be possible to defer the "ioremap" to a work queue too? Then we wouldn't need the special versions of ioremap.
For recoverable error, we can defer the "ioremap" to a work queue, because most recoverable action can take place only there in fact. But for fatal error, I think it is too late to be processed in a work queue, we need go panic as soon as possible to prevent data corruption.
Best Regards,
Huang Ying