From patchwork Wed Jan 3 19:39:41 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Manoj Iyer X-Patchwork-Id: 855194 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) by ozlabs.org (Postfix) with ESMTP id 3zBh8r68JTz9s74; Thu, 4 Jan 2018 06:39:56 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1eWotE-00063C-Kz; Wed, 03 Jan 2018 19:39:52 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.86_2) (envelope-from ) id 1eWotC-00062A-OZ for kernel-team@lists.ubuntu.com; Wed, 03 Jan 2018 19:39:50 +0000 Received: from cpe-24-28-20-247.austin.res.rr.com ([24.28.20.247] helo=canonical.com) by youngberry.canonical.com with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1eWotC-0001xD-7W for kernel-team@lists.ubuntu.com; Wed, 03 Jan 2018 19:39:50 +0000 From: Manoj Iyer To: kernel-team@lists.ubuntu.com Subject: [PATCH 1/2] ACPI: APEI: fix the wrong iteration of generic error status block Date: Wed, 3 Jan 2018 13:39:41 -0600 Message-Id: <20180103193942.25422-2-manoj.iyer@canonical.com> X-Mailer: git-send-email 2.14.1 In-Reply-To: <20180103193942.25422-1-manoj.iyer@canonical.com> References: <20180103193942.25422-1-manoj.iyer@canonical.com> X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: gengdongjiu The revision 0x300 generic error data entry is different from the old version, but currently iterating through the GHES estatus blocks does not take into account this difference. This will lead to failure to get the right data entry if GHES has revision 0x300 error data entry. Update the GHES estatus iteration macro to properly increment using acpi_hest_get_next(), and correct the iteration termination condition because the status block data length only includes error data length. Convert the CPER estatus checking and printing iteration logic to use same macro. BugLink: https://launchpad.net/bugs/1732990 Signed-off-by: Dongjiu Geng Tested-by: Tyler Baicar Reviewed-by: Borislav Petkov Signed-off-by: Rafael J. Wysocki (cherry picked from commit c4335fdd38227788178953c101b77180504d7ea0) Signed-off-by: Manoj Iyer --- drivers/acpi/apei/apei-internal.h | 5 ----- drivers/firmware/efi/cper.c | 12 ++---------- include/acpi/ghes.h | 5 +++++ 3 files changed, 7 insertions(+), 15 deletions(-) diff --git a/drivers/acpi/apei/apei-internal.h b/drivers/acpi/apei/apei-internal.h index 6e9f14c0a71b..cb4126051f62 100644 --- a/drivers/acpi/apei/apei-internal.h +++ b/drivers/acpi/apei/apei-internal.h @@ -120,11 +120,6 @@ int apei_exec_collect_resources(struct apei_exec_context *ctx, struct dentry; struct dentry *apei_get_debugfs_dir(void); -#define apei_estatus_for_each_section(estatus, section) \ - for (section = (struct acpi_hest_generic_data *)(estatus + 1); \ - (void *)section - (void *)estatus < estatus->data_length; \ - section = (void *)(section+1) + section->error_data_length) - static inline u32 cper_estatus_len(struct acpi_hest_generic_status *estatus) { if (estatus->raw_data_length) diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c index 48a8f69da42a..bf3672a81e49 100644 --- a/drivers/firmware/efi/cper.c +++ b/drivers/firmware/efi/cper.c @@ -606,7 +606,6 @@ void cper_estatus_print(const char *pfx, const struct acpi_hest_generic_status *estatus) { struct acpi_hest_generic_data *gdata; - unsigned int data_len; int sec_no = 0; char newpfx[64]; __u16 severity; @@ -617,14 +616,10 @@ void cper_estatus_print(const char *pfx, "It has been corrected by h/w " "and requires no further action"); printk("%s""event severity: %s\n", pfx, cper_severity_str(severity)); - data_len = estatus->data_length; - gdata = (struct acpi_hest_generic_data *)(estatus + 1); snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP); - while (data_len >= acpi_hest_get_size(gdata)) { + apei_estatus_for_each_section(estatus, gdata) { cper_estatus_print_section(newpfx, gdata, sec_no); - data_len -= acpi_hest_get_record_size(gdata); - gdata = acpi_hest_get_next(gdata); sec_no++; } } @@ -653,15 +648,12 @@ int cper_estatus_check(const struct acpi_hest_generic_status *estatus) if (rc) return rc; data_len = estatus->data_length; - gdata = (struct acpi_hest_generic_data *)(estatus + 1); - while (data_len >= acpi_hest_get_size(gdata)) { + apei_estatus_for_each_section(estatus, gdata) { gedata_len = acpi_hest_get_error_length(gdata); if (gedata_len > data_len - acpi_hest_get_size(gdata)) return -EINVAL; - data_len -= acpi_hest_get_record_size(gdata); - gdata = acpi_hest_get_next(gdata); } if (data_len) return -EINVAL; diff --git a/include/acpi/ghes.h b/include/acpi/ghes.h index 9f26e01186ae..9061c5c743b3 100644 --- a/include/acpi/ghes.h +++ b/include/acpi/ghes.h @@ -113,6 +113,11 @@ static inline void *acpi_hest_get_next(struct acpi_hest_generic_data *gdata) return (void *)(gdata) + acpi_hest_get_record_size(gdata); } +#define apei_estatus_for_each_section(estatus, section) \ + for (section = (struct acpi_hest_generic_data *)(estatus + 1); \ + (void *)section - (void *)(estatus + 1) < estatus->data_length; \ + section = acpi_hest_get_next(section)) + int ghes_notify_sea(void); #endif /* GHES_H */ From patchwork Wed Jan 3 19:39:42 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Manoj Iyer X-Patchwork-Id: 855195 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) by ozlabs.org (Postfix) with ESMTP id 3zBh8s6nhpz9s83; Thu, 4 Jan 2018 06:39:57 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1eWotF-00063t-Px; Wed, 03 Jan 2018 19:39:53 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.86_2) (envelope-from ) id 1eWotE-00062w-Dx for kernel-team@lists.ubuntu.com; Wed, 03 Jan 2018 19:39:52 +0000 Received: from cpe-24-28-20-247.austin.res.rr.com ([24.28.20.247] helo=canonical.com) by youngberry.canonical.com with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1eWotD-0001xN-Ve for kernel-team@lists.ubuntu.com; Wed, 03 Jan 2018 19:39:52 +0000 From: Manoj Iyer To: kernel-team@lists.ubuntu.com Subject: [PATCH 2/2] ACPI / APEI: clear error status before acknowledging the error Date: Wed, 3 Jan 2018 13:39:42 -0600 Message-Id: <20180103193942.25422-3-manoj.iyer@canonical.com> X-Mailer: git-send-email 2.14.1 In-Reply-To: <20180103193942.25422-1-manoj.iyer@canonical.com> References: <20180103193942.25422-1-manoj.iyer@canonical.com> X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Tyler Baicar Currently we acknowledge errors before clearing the error status. This could cause a new error to be populated by firmware in-between the error acknowledgment and the error status clearing which would cause the second error's status to be cleared without being handled. So, clear the error status before acknowledging the errors. Also, make sure to acknowledge the error if the error status read fails. BugLink: https://launchpad.net/bugs/1732990 Signed-off-by: Tyler Baicar Reviewed-by: Borislav Petkov Signed-off-by: Rafael J. Wysocki (cherry picked from commit aaf2c2fb0f51f91c699039440862b6ae9c25c10e) Signed-off-by: Manoj Iyer --- drivers/acpi/apei/ghes.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c index d661d452b238..8d43b1cecfbe 100644 --- a/drivers/acpi/apei/ghes.c +++ b/drivers/acpi/apei/ghes.c @@ -743,17 +743,19 @@ static int ghes_proc(struct ghes *ghes) } ghes_do_proc(ghes, ghes->estatus); +out: + ghes_clear_estatus(ghes); + + if (rc == -ENOENT) + return rc; + /* * GHESv2 type HEST entries introduce support for error acknowledgment, * so only acknowledge the error if this support is present. */ - if (is_hest_type_generic_v2(ghes)) { - rc = ghes_ack_error(ghes->generic_v2); - if (rc) - return rc; - } -out: - ghes_clear_estatus(ghes); + if (is_hest_type_generic_v2(ghes)) + return ghes_ack_error(ghes->generic_v2); + return rc; }