From: Junhao He <hejunhao3@h-partners.com> driver inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8377 --------------------------------------------------------------------------- The do_sea() function defaults to using firmware-first mode, if supported. It invoke acpi/apei/ghes ghes_notify_sea() to report and handling the SEA error, The GHES uses a buffer to cache the most recent 4 kinds of SEA errors. If the same kind SEA error occurs again, GHES will skip to reporting this SEA error and will not add it to the "ghes_estatus_llist" list until the cache times out after 10 seconds, at which point the SEA error will be reprocessed. The GHES invoke ghes_proc_in_irq() to handle the SEA error, which ultimately executes memory_failure to process the page with hardware memory corruption. If the same SEA error appears multiple times consecutively, it indicates that the previous handling was incomplete or unable to resolve the fault. In such cases, it is more appropriate to return a failure when encountering the same error again, and then proceed to arm64_do_kernel_sea for further processing. When hardware memory corruption occurs, a memory error interrupt is triggered. If the kernel accesses this erroneous data, it will trigget the SEA error exception handler. All such handlers will call memory_failure() to handle the faulty page. If a memory error interrupt occurs first, followed by an SEA error interrupt, the faulty page is first marked as poisoned by the memory error interrupt process, and then the SEA error interrupt handling process will send a SIGBUS signel to the process accessing the poisoned page. However, if the SEA interrupt is reported first, the following exceptional scenario occurs: When a user process directly requests and accesses a page with hardware memory corruption via mmap (such as with devmem), the page containing this address may still be in a free buddy state in the kernel. At this point, the page is marked as "poisoned" during the SEA claim memory_failure(). However, since the process does not request the page through the kernel's MMU, the kernel cannot send SIGBUS signel to the processes. And the memory error interrupt handling process not support send SIGBUS signel. As a result, these processes continues to access the faulty page, causing repeated entries into the SEA exception handler. At this time, it lead to an SEA error interrupt storm. The following error logs is explained using the devmem process: NOTICE: SEA Handle NOTICE: SpsrEl3 = 0x60001000, ELR_EL3 = 0xffffc6ab42671400 NOTICE: skt[0x0]die[0x0]cluster[0x0]core[0x1] NOTICE: EsrEl3 = 0x92000410 NOTICE: PA is valid: 0x1000093c00 NOTICE: Hest Set GenericError Data [ 1419.542401][ C1] {57}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9 [ 1419.551435][ C1] {57}[Hardware Error]: event severity: recoverable [ 1419.557865][ C1] {57}[Hardware Error]: Error 0, type: recoverable [ 1419.564295][ C1] {57}[Hardware Error]: section_type: ARM processor error [ 1419.571421][ C1] {57}[Hardware Error]: MIDR: 0x0000000000000000 [ 1419.571434][ C1] {57}[Hardware Error]: Multiprocessor Affinity Register (MPIDR): 0x0000000081000100 [ 1419.586813][ C1] {57}[Hardware Error]: error affinity level: 0 [ 1419.586821][ C1] {57}[Hardware Error]: running state: 0x1 [ 1419.602714][ C1] {57}[Hardware Error]: Power State Coordination Interface state: 0 [ 1419.602724][ C1] {57}[Hardware Error]: Error info structure 0: [ 1419.614797][ C1] {57}[Hardware Error]: num errors: 1 [ 1419.614804][ C1] {57}[Hardware Error]: error_type: 0, cache error [ 1419.629226][ C1] {57}[Hardware Error]: error_info: 0x0000000020400014 [ 1419.629234][ C1] {57}[Hardware Error]: cache level: 1 [ 1419.642006][ C1] {57}[Hardware Error]: the error has not been corrected [ 1419.642013][ C1] {57}[Hardware Error]: physical fault address: 0x0000001000093c00 [ 1419.654001][ C1] {57}[Hardware Error]: Vendor specific error info has 48 bytes: [ 1419.654014][ C1] {57}[Hardware Error]: 00000000: 00000000 00000000 00000000 00000000 ................ [ 1419.670685][ C1] {57}[Hardware Error]: 00000010: 00000000 00000000 00000000 00000000 ................ [ 1419.670692][ C1] {57}[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................ [ 1419.783606][T54990] Memory failure: 0x1000093: recovery action for free buddy page: Recovered [ 1419.919580][ T9955] EDAC MC0: 1 UE Multi-bit ECC on unknown memory (node:0 card:1 module:71 bank:7 row:0 col:0 page:0x1000093 offset:0xc00 grain:1 - APEI location: node:0 card:257 module:71 bank:7 row:0 col:0) NOTICE: SEA Handle NOTICE: SpsrEl3 = 0x60001000, ELR_EL3 = 0xffffc6ab42671400 NOTICE: skt[0x0]die[0x0]cluster[0x0]core[0x1] NOTICE: EsrEl3 = 0x92000410 NOTICE: PA is valid: 0x1000093c00 NOTICE: Hest Set GenericError Data NOTICE: SEA Handle NOTICE: SpsrEl3 = 0x60001000, ELR_EL3 = 0xffffc6ab42671400 NOTICE: skt[0x0]die[0x0]cluster[0x0]core[0x1] NOTICE: EsrEl3 = 0x92000410 NOTICE: PA is valid: 0x1000093c00 NOTICE: Hest Set GenericError Data ... ---> Hapend SEA error interrupt storm NOTICE: SEA Handle NOTICE: SpsrEl3 = 0x60001000, ELR_EL3 = 0xffffc6ab42671400 NOTICE: skt[0x0]die[0x0]cluster[0x0]core[0x1] NOTICE: EsrEl3 = 0x92000410 NOTICE: PA is valid: 0x1000093c00 NOTICE: Hest Set GenericError Data [ 1429.818080][ T9955] Memory failure: 0x1000093: already hardware poisoned [ 1429.825760][ C1] ghes_print_estatus: 1 callbacks suppressed [ 1429.825763][ C1] {59}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 9 [ 1429.843731][ C1] {59}[Hardware Error]: event severity: recoverable [ 1429.861800][ C1] {59}[Hardware Error]: Error 0, type: recoverable [ 1429.874658][ C1] {59}[Hardware Error]: section_type: ARM processor error [ 1429.887516][ C1] {59}[Hardware Error]: MIDR: 0x0000000000000000 [ 1429.901159][ C1] {59}[Hardware Error]: Multiprocessor Affinity Register (MPIDR): 0x0000000081000100 [ 1429.901166][ C1] {59}[Hardware Error]: error affinity level: 0 [ 1429.914896][ C1] {59}[Hardware Error]: running state: 0x1 [ 1429.914903][ C1] {59}[Hardware Error]: Power State Coordination Interface state: 0 [ 1429.933319][ C1] {59}[Hardware Error]: Error info structure 0: [ 1429.946261][ C1] {59}[Hardware Error]: num errors: 1 [ 1429.946269][ C1] {59}[Hardware Error]: error_type: 0, cache error [ 1429.970847][ C1] {59}[Hardware Error]: error_info: 0x0000000020400014 [ 1429.970854][ C1] {59}[Hardware Error]: cache level: 1 [ 1429.988406][ C1] {59}[Hardware Error]: the error has not been corrected [ 1430.013419][ C1] {59}[Hardware Error]: physical fault address: 0x0000001000093c00 [ 1430.013425][ C1] {59}[Hardware Error]: Vendor specific error info has 48 bytes: [ 1430.025424][ C1] {59}[Hardware Error]: 00000000: 00000000 00000000 00000000 00000000 ................ [ 1430.053736][ C1] {59}[Hardware Error]: 00000010: 00000000 00000000 00000000 00000000 ................ [ 1430.066341][ C1] {59}[Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................ [ 1430.294255][T54990] Memory failure: 0x1000093: already hardware poisoned [ 1430.305518][T54990] 0x1000093: Sending SIGBUS to devmem:54990 due to hardware memory corruption Signed-off-by: Junhao He <hejunhao3@h-partners.com> --- drivers/acpi/apei/ghes.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index e638fa4b7426..5b585e43a4cc 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -1129,8 +1129,10 @@ static int ghes_in_nmi_queue_one_entry(struct ghes *ghes, ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx); /* This error has been reported before, don't process it again. */ - if (ghes_estatus_cached(estatus)) + if (ghes_estatus_cached(estatus)) { + rc = -ECANCELED; goto no_work; + } llist_add(&estatus_node->llnode, &ghes_estatus_llist); -- 2.33.0