linux-dev/drivers/acpi/apei, branch linus/master

ACPI, APEI, EINJ: Refuse to inject into the zero page

2022-04-22T14:52:27Z

Some validation tests dynamically inject errors into memory used by applications to check that the system can recover from a variety of poison consumption sceenarios. But sometimes the virtual address picked by these tests is mapped to the zero page. This causes additional unexpected machine checks as other processes that map the zero page also consume the poison. Disallow injection to the zero page. Signed-off-by: Tony Luck Signed-off-by: Rafael J. Wysocki

ACPI: APEI: Fix missing ERST record id

2022-04-13T18:29:24Z

Read a record is cleared by others, but the deleted record cache entry is still created by erst_get_record_id_next. When next enumerate the records, get the cached deleted record, then erst_read() return -ENOENT and try to get next record, loop back to first ID will return 0 in function __erst_record_id_cache_add_one and then set record_id as APEI_ERST_INVALID_RECORD_ID, finished this time read operation. It will result in read the records just in the cache hereafter. This patch cleared the deleted record cache, fix the issue that "./erst-inject -p" shows record counts not equal to "./erst-inject -n". A reproducer of the problem(retry many times): [root@localhost erst-inject]# ./erst-inject -c 0xaaaaa00011 [root@localhost erst-inject]# ./erst-inject -p rc: 273 rcd sig: CPER rcd id: 0xaaaaa00012 rc: 273 rcd sig: CPER rcd id: 0xaaaaa00013 rc: 273 rcd sig: CPER rcd id: 0xaaaaa00014 [root@localhost erst-inject]# ./erst-inject -i 0xaaaaa000006 [root@localhost erst-inject]# ./erst-inject -i 0xaaaaa000007 [root@localhost erst-inject]# ./erst-inject -i 0xaaaaa000008 [root@localhost erst-inject]# ./erst-inject -p rc: 273 rcd sig: CPER rcd id: 0xaaaaa00012 rc: 273 rcd sig: CPER rcd id: 0xaaaaa00013 rc: 273 rcd sig: CPER rcd id: 0xaaaaa00014 [root@localhost erst-inject]# ./erst-inject -n total error record count: 6 Signed-off-by: Liu Xinpeng Reviewed-by: Tony Luck Signed-off-by: Rafael J. Wysocki

ACPI, APEI: Use the correct variable for sizeof()

2022-03-22T17:52:21Z

While the original code is valid, it is not the obvious choice for the sizeof() call and in preparation to limit the scope of the list iterator variable the sizeof should be changed to the size of the variable being allocated. Signed-off-by: Jakob Koschel Signed-off-by: Rafael J. Wysocki

ACPI/APEI: Limit printable size of BERT table data

2022-03-09T18:40:13Z

Platforms with large BERT table data can trigger soft lockup errors while attempting to print the entire BERT table data to the console at boot: watchdog: BUG: soft lockup - CPU#160 stuck for 23s! [swapper/0:1] Observed on Ampere Altra systems with a single BERT record of ~250KB. The original bert driver appears to have assumed relatively small table data. Since it is impractical to reassemble large table data from interwoven console messages, and the table data is available in /sys/firmware/acpi/tables/data/BERT limit the size for tables printed to the console to 1024 (for no reason other than it seemed like a good place to kick off the discussion, would appreciate feedback from existing users in terms of what size would maintain their current usage model). Alternatively, we could make printing a CONFIG option, use the bert_disable boot arg (or something similar), or use a debug log level. However, all those solutions require extra steps or change the existing behavior for small table data. Limiting the size preserves existing behavior on existing platforms with small table data, and eliminates the soft lockups for platforms with large table data, while still making it available. Signed-off-by: Darren Hart Signed-off-by: Rafael J. Wysocki

ACPI: APEI: fix return value of __setup handlers

2022-03-08T18:43:39Z

__setup() handlers should return 1 to indicate that the boot option has been handled. Returning 0 causes a boot option to be listed in the Unknown kernel command line parameters and also added to init's arg list (if no '=' sign) or environment list (if of the form 'a=b'). Unknown kernel command line parameters "erst_disable bert_disable hest_disable BOOT_IMAGE=/boot/bzImage-517rc6", will be passed to user space. Run /sbin/init as init process with arguments: /sbin/init erst_disable bert_disable hest_disable with environment: HOME=/ TERM=linux BOOT_IMAGE=/boot/bzImage-517rc6 Fixes: a3e2acc5e37b ("ACPI / APEI: Add Boot Error Record Table (BERT) support") Fixes: a08f82d08053 ("ACPI, APEI, Error Record Serialization Table (ERST) support") Fixes: 9dc966641677 ("ACPI, APEI, HEST table parsing") Signed-off-by: Randy Dunlap Reported-by: Igor Zhbanov Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru Reviewed-by: "Huang, Ying" Signed-off-by: Rafael J. Wysocki

ACPI: APEI: rename ghes_init() with an "acpi_" prefix

2022-03-03T19:25:23Z

ghes_init() sticks out in acpi_init() because it is the only functions without an "acpi_" prefix. Rename ghes_init with an "acpi_" prefix, then all looks fine. Signed-off-by: Shuai Xue Signed-off-by: Rafael J. Wysocki

ACPI: APEI: explicit init of HEST and GHES in apci_init()

2022-03-03T19:24:22Z

From commit e147133a42cb ("ACPI / APEI: Make hest.c manage the estatus memory pool") was merged, ghes_init() relies on acpi_hest_init() to manage the estatus memory pool. On the other hand, ghes_init() relies on sdei_init() to detect the SDEI version and (un)register events. The dependencies are as follows: ghes_init() => acpi_hest_init() => acpi_bus_init() => acpi_init() ghes_init() => sdei_init() HEST is not PCI-specific and initcall ordering is implicit and not well-defined within a level. Based on above, remove acpi_hest_init() from acpi_pci_root_init() and convert ghes_init() and sdei_init() from initcalls to explicit calls in the following order: acpi_hest_init() ghes_init() sdei_init() Signed-off-by: Shuai Xue Signed-off-by: Rafael J. Wysocki

x86/sgx: Add check for SGX pages to ghes_do_memory_failure()

2021-11-15T19:13:16Z

SGX EPC pages do not have a "struct page" associated with them so the pfn_valid() sanity check fails and results in a warning message to the console. Add an additional check to skip the warning if the address of the error is in an SGX EPC page. Signed-off-by: Tony Luck Signed-off-by: Dave Hansen Reviewed-by: Jarkko Sakkinen Tested-by: Reinette Chatre Link: https://lkml.kernel.org/r/20211026220050.697075-8-tony.luck@intel.com

x86/sgx: Add hook to error injection address validation

2021-11-15T19:13:16Z

SGX reserved memory does not appear in the standard address maps. Add hook to call into the SGX code to check if an address is located in SGX memory. There are other challenges in injecting errors into SGX. Update the documentation with a sequence of operations to inject. Signed-off-by: Tony Luck Signed-off-by: Dave Hansen Reviewed-by: Jarkko Sakkinen Tested-by: Reinette Chatre Link: https://lkml.kernel.org/r/20211026220050.697075-7-tony.luck@intel.com

ACPI: APEI: mark apei_hest_parse() static

2021-10-27T18:34:47Z

apei_hest_parse() is only used in hest.c, so mark it static. Signed-off-by: Christoph Hellwig [ rjw: Minor subject and changelog edits ] Signed-off-by: Rafael J. Wysocki