From 7ed28f2ed43ece424ff2fa4dedac7928bb37a23a Mon Sep 17 00:00:00 2001 From: Jiang Liu Date: Wed, 7 Mar 2012 22:15:06 +0800 Subject: ACPI, APEI, Fix ERST header length check This fixes a trivial copy & paste error in ERST header length check. It's just for future safety because sizeof(struct acpi_table_einj) equals to sizeof(struct acpi_table_erst) with current ACPI5.0 specification. It applies to v3.3-rc6. Signed-off-by: Jiang Liu Acked-by: Huang Ying Signed-off-by: Len Brown --- drivers/acpi/apei/erst.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/acpi/apei') diff --git a/drivers/acpi/apei/erst.c b/drivers/acpi/apei/erst.c index eb9fab5b96e..e4d9d24eb73 100644 --- a/drivers/acpi/apei/erst.c +++ b/drivers/acpi/apei/erst.c @@ -917,7 +917,7 @@ static int erst_check_table(struct acpi_table_erst *erst_tab) { if ((erst_tab->header_length != (sizeof(struct acpi_table_erst) - sizeof(erst_tab->header))) - && (erst_tab->header_length != sizeof(struct acpi_table_einj))) + && (erst_tab->header_length != sizeof(struct acpi_table_erst))) return -EINVAL; if (erst_tab->header.length < sizeof(struct acpi_table_erst)) return -EINVAL; -- cgit v1.2.3-18-g5258 From 185210cc754754c2504afcef9d1c9cd4b8761a9c Mon Sep 17 00:00:00 2001 From: Chen Gong Date: Sat, 3 Mar 2012 11:56:43 +0800 Subject: ACPI, APEI, EINJ, limit the range of einj_param On the platforms with ACPI4.x support, parameter extension is not always doable, which means only parameter extension is enabled, einj_param can take effect. v2->v1: stopping early in einj_get_parameter_address for einj_param Signed-off-by: Chen Gong Acked-by: Tony Luck Signed-off-by: Len Brown --- drivers/acpi/apei/einj.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'drivers/acpi/apei') diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c index 4ca087dd5f4..3d3816f6d36 100644 --- a/drivers/acpi/apei/einj.c +++ b/drivers/acpi/apei/einj.c @@ -238,7 +238,7 @@ static void *einj_get_parameter_address(void) return v5param; } } - if (paddrv4) { + if (param_extension && paddrv4) { struct einj_parameter *v4param; v4param = acpi_os_map_memory(paddrv4, sizeof(*v4param)); -- cgit v1.2.3-18-g5258 From ee49089dc7d9fc78db51e18f4fba68e88edc49a4 Mon Sep 17 00:00:00 2001 From: Chen Gong Date: Thu, 15 Mar 2012 16:53:36 +0800 Subject: ACPI, APEI, EINJ, new parameter to control trigger action Some APEI firmware implementation will access injected address specified in param1 to trigger the error when injecting memory error, which means if one SRAR error is injected, the crash always happens because it is executed in kernel context. This new parameter can disable trigger action and control is taken over by the user. In this way, an SRAR error can happen in user context instead of crashing the system. This function is highly depended on BIOS implementation so please ensure you know the BIOS trigger procedure before you enable this switch. v2: notrigger should be created together with param1/param2 Tested-by: Tony Luck Signed-off-by: Chen Gong Signed-off-by: Len Brown --- drivers/acpi/apei/einj.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) (limited to 'drivers/acpi/apei') diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c index 3d3816f6d36..8e1793649ec 100644 --- a/drivers/acpi/apei/einj.c +++ b/drivers/acpi/apei/einj.c @@ -74,6 +74,8 @@ struct vendor_error_type_extension { u8 reserved[3]; }; +static u32 notrigger; + static u32 vendor_flags; static struct debugfs_blob_wrapper vendor_blob; static char vendor_dev[64]; @@ -496,9 +498,11 @@ static int __einj_error_inject(u32 type, u64 param1, u64 param2) if (rc) return rc; trigger_paddr = apei_exec_ctx_get_output(&ctx); - rc = __einj_error_trigger(trigger_paddr, type, param1, param2); - if (rc) - return rc; + if (notrigger == 0) { + rc = __einj_error_trigger(trigger_paddr, type, param1, param2); + if (rc) + return rc; + } rc = apei_exec_run_optional(&ctx, ACPI_EINJ_END_OPERATION); return rc; @@ -700,6 +704,11 @@ static int __init einj_init(void) einj_debug_dir, &error_param2); if (!fentry) goto err_unmap; + + fentry = debugfs_create_x32("notrigger", S_IRUSR | S_IWUSR, + einj_debug_dir, ¬rigger); + if (!fentry) + goto err_unmap; } if (vendor_dev[0]) { -- cgit v1.2.3-18-g5258 From 15afae604651d4e17652d2ffb56f5e36f991cfef Mon Sep 17 00:00:00 2001 From: Gary Hade Date: Wed, 21 Mar 2012 15:28:50 -0700 Subject: ACPI, APEI: Fix incorrect APEI register bit width check and usage The current code incorrectly assumes that (1) the APEI register bit width is always 8, 16, 32, or 64 and (2) the APEI register bit width is always equal to the APEI register access width. ERST serialization instructions entries such as: [030h 0048 1] Action : 00 [Begin Write Operation] [031h 0049 1] Instruction : 03 [Write Register Value] [032h 0050 1] Flags (decoded below) : 01 Preserve Register Bits : 1 [033h 0051 1] Reserved : 00 [034h 0052 12] Register Region : [Generic Address Structure] [034h 0052 1] Space ID : 00 [SystemMemory] [035h 0053 1] Bit Width : 03 [036h 0054 1] Bit Offset : 00 [037h 0055 1] Encoded Access Width : 03 [DWord Access:32] [038h 0056 8] Address : 000000007F2D7038 [040h 0064 8] Value : 0000000000000001 [048h 0072 8] Mask : 0000000000000007 break this assumption by yielding: [Firmware Bug]: APEI: Invalid bit width in GAR [0x7f2d7038/3/0] I have found no ACPI specification requirements corresponding with the above assumptions. There is even a good example in the Serialization Instruction Entries section (ACPI 4.0 section 17.4,1.2, ACPI 4.0a section 2.5.1.2, ACPI 5.0 section 18.5.1.2) that mentions a serialization instruction with a bit range of [6:2] which is 5 bits wide, _not_ 8, 16, 32, or 64 bits wide. Compile and boot tested with 3.3.0-rc7 on a IBM HX5. Signed-off-by: Gary Hade Signed-off-by: Len Brown --- drivers/acpi/apei/apei-base.c | 61 ++++++++++++++++++++++++++++--------------- 1 file changed, 40 insertions(+), 21 deletions(-) (limited to 'drivers/acpi/apei') diff --git a/drivers/acpi/apei/apei-base.c b/drivers/acpi/apei/apei-base.c index e5d53b7ddc7..1d3656f6919 100644 --- a/drivers/acpi/apei/apei-base.c +++ b/drivers/acpi/apei/apei-base.c @@ -558,33 +558,48 @@ void apei_resources_release(struct apei_resources *resources) } EXPORT_SYMBOL_GPL(apei_resources_release); -static int apei_check_gar(struct acpi_generic_address *reg, u64 *paddr) +static int apei_check_gar(struct acpi_generic_address *reg, u64 *paddr, + u32 *access_bit_width) { - u32 width, space_id; + u32 bit_width, bit_offset, access_size_code, space_id; - width = reg->bit_width; + bit_width = reg->bit_width; + bit_offset = reg->bit_offset; + access_size_code = reg->access_width; space_id = reg->space_id; /* Handle possible alignment issues */ memcpy(paddr, ®->address, sizeof(*paddr)); if (!*paddr) { pr_warning(FW_BUG APEI_PFX - "Invalid physical address in GAR [0x%llx/%u/%u]\n", - *paddr, width, space_id); + "Invalid physical address in GAR [0x%llx/%u/%u/%u/%u]\n", + *paddr, bit_width, bit_offset, access_size_code, + space_id); return -EINVAL; } - if ((width != 8) && (width != 16) && (width != 32) && (width != 64)) { + if (access_size_code < 1 || access_size_code > 4) { pr_warning(FW_BUG APEI_PFX - "Invalid bit width in GAR [0x%llx/%u/%u]\n", - *paddr, width, space_id); + "Invalid access size code in GAR [0x%llx/%u/%u/%u/%u]\n", + *paddr, bit_width, bit_offset, access_size_code, + space_id); + return -EINVAL; + } + *access_bit_width = 1UL << (access_size_code + 2); + + if ((bit_width + bit_offset) > *access_bit_width) { + pr_warning(FW_BUG APEI_PFX + "Invalid bit width + offset in GAR [0x%llx/%u/%u/%u/%u]\n", + *paddr, bit_width, bit_offset, access_size_code, + space_id); return -EINVAL; } if (space_id != ACPI_ADR_SPACE_SYSTEM_MEMORY && space_id != ACPI_ADR_SPACE_SYSTEM_IO) { pr_warning(FW_BUG APEI_PFX - "Invalid address space type in GAR [0x%llx/%u/%u]\n", - *paddr, width, space_id); + "Invalid address space type in GAR [0x%llx/%u/%u/%u/%u]\n", + *paddr, bit_width, bit_offset, access_size_code, + space_id); return -EINVAL; } @@ -595,23 +610,25 @@ static int apei_check_gar(struct acpi_generic_address *reg, u64 *paddr) int apei_read(u64 *val, struct acpi_generic_address *reg) { int rc; + u32 access_bit_width; u64 address; acpi_status status; - rc = apei_check_gar(reg, &address); + rc = apei_check_gar(reg, &address, &access_bit_width); if (rc) return rc; *val = 0; switch(reg->space_id) { case ACPI_ADR_SPACE_SYSTEM_MEMORY: - status = acpi_os_read_memory64((acpi_physical_address) - address, val, reg->bit_width); + status = acpi_os_read_memory64((acpi_physical_address) address, + val, access_bit_width); if (ACPI_FAILURE(status)) return -EIO; break; case ACPI_ADR_SPACE_SYSTEM_IO: - status = acpi_os_read_port(address, (u32 *)val, reg->bit_width); + status = acpi_os_read_port(address, (u32 *)val, + access_bit_width); if (ACPI_FAILURE(status)) return -EIO; break; @@ -627,22 +644,23 @@ EXPORT_SYMBOL_GPL(apei_read); int apei_write(u64 val, struct acpi_generic_address *reg) { int rc; + u32 access_bit_width; u64 address; acpi_status status; - rc = apei_check_gar(reg, &address); + rc = apei_check_gar(reg, &address, &access_bit_width); if (rc) return rc; switch (reg->space_id) { case ACPI_ADR_SPACE_SYSTEM_MEMORY: - status = acpi_os_write_memory64((acpi_physical_address) - address, val, reg->bit_width); + status = acpi_os_write_memory64((acpi_physical_address) address, + val, access_bit_width); if (ACPI_FAILURE(status)) return -EIO; break; case ACPI_ADR_SPACE_SYSTEM_IO: - status = acpi_os_write_port(address, val, reg->bit_width); + status = acpi_os_write_port(address, val, access_bit_width); if (ACPI_FAILURE(status)) return -EIO; break; @@ -661,23 +679,24 @@ static int collect_res_callback(struct apei_exec_context *ctx, struct apei_resources *resources = data; struct acpi_generic_address *reg = &entry->register_region; u8 ins = entry->instruction; + u32 access_bit_width; u64 paddr; int rc; if (!(ctx->ins_table[ins].flags & APEI_EXEC_INS_ACCESS_REGISTER)) return 0; - rc = apei_check_gar(reg, &paddr); + rc = apei_check_gar(reg, &paddr, &access_bit_width); if (rc) return rc; switch (reg->space_id) { case ACPI_ADR_SPACE_SYSTEM_MEMORY: return apei_res_add(&resources->iomem, paddr, - reg->bit_width / 8); + access_bit_width / 8); case ACPI_ADR_SPACE_SYSTEM_IO: return apei_res_add(&resources->ioport, paddr, - reg->bit_width / 8); + access_bit_width / 8); default: return -EINVAL; } -- cgit v1.2.3-18-g5258 From 37d2a3622d249d83413c92a1cd9e94b5237d0fcc Mon Sep 17 00:00:00 2001 From: Jiang Liu Date: Wed, 15 Feb 2012 00:01:44 +0800 Subject: CPER failed to handle generic error records with multiple sections The function apei_estatus_print() and apei_estatus_check() forget to move ahead the gdata pointer when dealing with multiple generic error data sections. Signed-off-by: Jiang Liu Signed-off-by: Len Brown --- drivers/acpi/apei/cper.c | 2 ++ 1 file changed, 2 insertions(+) (limited to 'drivers/acpi/apei') diff --git a/drivers/acpi/apei/cper.c b/drivers/acpi/apei/cper.c index 5d4189464d6..e6defd86b42 100644 --- a/drivers/acpi/apei/cper.c +++ b/drivers/acpi/apei/cper.c @@ -362,6 +362,7 @@ void apei_estatus_print(const char *pfx, gedata_len = gdata->error_data_length; apei_estatus_print_section(pfx, gdata, sec_no); data_len -= gedata_len + sizeof(*gdata); + gdata = (void *)(gdata + 1) + gedata_len; sec_no++; } } @@ -396,6 +397,7 @@ int apei_estatus_check(const struct acpi_hest_generic_status *estatus) if (gedata_len > data_len - sizeof(*gdata)) return -EINVAL; data_len -= gedata_len + sizeof(*gdata); + gdata = (void *)(gdata + 1) + gedata_len; } if (data_len) return -EINVAL; -- cgit v1.2.3-18-g5258