From: Tyler Baicar OS <baicar@os.amperecomputing.com> To: James Morse <james.morse@arm.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Cc: Mark Rutland <mark.rutland@arm.com>, Tony Luck <tony.luck@intel.com>, Xie XiuQi <xiexiuqi@huawei.com>, Catalin Marinas <catalin.marinas@arm.com>, Rafael Wysocki <rjw@rjwysocki.net>, Tyler Baicar <tyler@amperecomputing.com>, Borislav Petkov <bp@alien8.de>, Andrew Morton <akpm@linux-foundation.org>, Will Deacon <will@kernel.org>, Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>, Len Brown <lenb@kernel.org> Subject: Re: [PATCH 2/3] ACPI / APEI: Kick the memory_failure() queue for synchronous errors Date: Mon, 9 Mar 2020 17:07:50 +0000 [thread overview] Message-ID: <CY1PR01MB2137B6CC34E2D31F7618A951E3FE0@CY1PR01MB2137.prod.exchangelabs.com> (raw) In-Reply-To: <20200228174817.74278-3-james.morse@arm.com> Hello James, On Fri, Feb 28, 2020 at 12:49 PM James Morse <james.morse@arm.com> wrote: > > -static void ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, int sev) > +static bool ghes_handle_memory_failure(struct ghes *ghes, > + struct acpi_hest_generic_data *gdata, > + int sev) It doesn't look like ghes needs to be added as a parameter to this function, unless I'm missing something :) > { > -#ifdef CONFIG_ACPI_APEI_MEMORY_FAILURE > unsigned long pfn; > int flags = -1; > int sec_sev = ghes_severity(gdata->error_severity); > struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata); > > + if (!IS_ENABLED(CONFIG_ACPI_APEI_MEMORY_FAILURE)) > + return false; > + > if (!(mem_err->validation_bits & CPER_MEM_VALID_PA)) > - return; > + return false; > > pfn = mem_err->physical_addr >> PAGE_SHIFT; > if (!pfn_valid(pfn)) { > pr_warn_ratelimited(FW_WARN GHES_PFX > "Invalid address in generic error data: %#llx\n", > mem_err->physical_addr); > - return; > + return false; > } > > /* iff following two events can be handled properly by now */ > @@ -440,9 +465,12 @@ static void ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, int > if (sev == GHES_SEV_RECOVERABLE && sec_sev == GHES_SEV_RECOVERABLE) > flags = 0; > > - if (flags != -1) > + if (flags != -1) { > memory_failure_queue(pfn, flags); > -#endif > + return true; > + } > + > + return false; > } > This series looks good to me overall. I'm going to pull it and give it a spin. Thanks, Tyler
WARNING: multiple messages have this Message-ID (diff)
From: Tyler Baicar OS <baicar@os.amperecomputing.com> To: James Morse <james.morse@arm.com>, "linux-mm@kvack.org" <linux-mm@kvack.org>, "linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Cc: Mark Rutland <mark.rutland@arm.com>, Tony Luck <tony.luck@intel.com>, Will Deacon <will@kernel.org>, Xie XiuQi <xiexiuqi@huawei.com>, Catalin Marinas <catalin.marinas@arm.com>, Rafael Wysocki <rjw@rjwysocki.net>, Borislav Petkov <bp@alien8.de>, Andrew Morton <akpm@linux-foundation.org>, Tyler Baicar <tyler@amperecomputing.com>, Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>, Len Brown <lenb@kernel.org> Subject: Re: [PATCH 2/3] ACPI / APEI: Kick the memory_failure() queue for synchronous errors Date: Mon, 9 Mar 2020 17:07:50 +0000 [thread overview] Message-ID: <CY1PR01MB2137B6CC34E2D31F7618A951E3FE0@CY1PR01MB2137.prod.exchangelabs.com> (raw) In-Reply-To: <20200228174817.74278-3-james.morse@arm.com> Hello James, On Fri, Feb 28, 2020 at 12:49 PM James Morse <james.morse@arm.com> wrote: > > -static void ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, int sev) > +static bool ghes_handle_memory_failure(struct ghes *ghes, > + struct acpi_hest_generic_data *gdata, > + int sev) It doesn't look like ghes needs to be added as a parameter to this function, unless I'm missing something :) > { > -#ifdef CONFIG_ACPI_APEI_MEMORY_FAILURE > unsigned long pfn; > int flags = -1; > int sec_sev = ghes_severity(gdata->error_severity); > struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata); > > + if (!IS_ENABLED(CONFIG_ACPI_APEI_MEMORY_FAILURE)) > + return false; > + > if (!(mem_err->validation_bits & CPER_MEM_VALID_PA)) > - return; > + return false; > > pfn = mem_err->physical_addr >> PAGE_SHIFT; > if (!pfn_valid(pfn)) { > pr_warn_ratelimited(FW_WARN GHES_PFX > "Invalid address in generic error data: %#llx\n", > mem_err->physical_addr); > - return; > + return false; > } > > /* iff following two events can be handled properly by now */ > @@ -440,9 +465,12 @@ static void ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, int > if (sev == GHES_SEV_RECOVERABLE && sec_sev == GHES_SEV_RECOVERABLE) > flags = 0; > > - if (flags != -1) > + if (flags != -1) { > memory_failure_queue(pfn, flags); > -#endif > + return true; > + } > + > + return false; > } > This series looks good to me overall. I'm going to pull it and give it a spin. Thanks, Tyler _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-03-09 17:07 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-02-28 17:48 [PATCH 0/3] ACPI / APEI: Kick the memory_failure() queue for synchronous errors James Morse 2020-02-28 17:48 ` James Morse 2020-02-28 17:48 ` [PATCH 1/3] mm/memory-failure: Add memory_failure_queue_kick() James Morse 2020-02-28 17:48 ` James Morse 2020-02-28 17:48 ` [PATCH 2/3] ACPI / APEI: Kick the memory_failure() queue for synchronous errors James Morse 2020-02-28 17:48 ` James Morse 2020-03-09 17:07 ` Tyler Baicar OS [this message] 2020-03-09 17:07 ` Tyler Baicar OS 2020-03-09 17:07 ` Tyler Baicar OS 2020-02-28 17:48 ` [PATCH 3/3] arm64: acpi: Make apei_claim_sea() synchronise with APEI's irq work James Morse 2020-02-28 17:48 ` James Morse 2020-03-24 16:41 ` Catalin Marinas 2020-03-24 16:41 ` Catalin Marinas 2020-03-20 19:19 ` [PATCH 0/3] ACPI / APEI: Kick the memory_failure() queue for synchronous errors Tyler Baicar OS 2020-03-20 19:19 ` Tyler Baicar OS 2020-03-20 19:19 ` Tyler Baicar OS
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CY1PR01MB2137B6CC34E2D31F7618A951E3FE0@CY1PR01MB2137.prod.exchangelabs.com \ --to=baicar@os.amperecomputing.com \ --cc=akpm@linux-foundation.org \ --cc=bp@alien8.de \ --cc=catalin.marinas@arm.com \ --cc=james.morse@arm.com \ --cc=lenb@kernel.org \ --cc=linux-acpi@vger.kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-mm@kvack.org \ --cc=mark.rutland@arm.com \ --cc=n-horiguchi@ah.jp.nec.com \ --cc=rjw@rjwysocki.net \ --cc=tony.luck@intel.com \ --cc=tyler@amperecomputing.com \ --cc=will@kernel.org \ --cc=xiexiuqi@huawei.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.