From: Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
Cc: "Jonathan (Zhixiong) Zhang"
<zjzhang-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
"H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Matt Fleming
<matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
Borislav Petkov <bp-l3A5Bk7waGM@public.gmane.org>,
Ard Biesheuvel
<ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Catalin Marinas <Catalin.Marinas-5wv7dgnIgG8@public.gmane.org>
Subject: Re: [PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory
Date: Fri, 4 Sep 2015 13:36:00 +0200 [thread overview]
Message-ID: <20150904113559.GA21396@gmail.com> (raw)
In-Reply-To: <20150904112820.GB2737-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
* Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> wrote:
> On Tue, 25 Aug, at 10:27:22AM, Jonathan (Zhixiong) Zhang wrote:
> > From: "Jonathan (Zhixiong) Zhang" <zjzhang-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> >
> > If the ACPI APEI firmware handles hardware error first (called "firmware
> > first handling"), the firmware updates the GHES memory region with hardware
> > error record (called "generic hardware error record"). Essentially the
> > firmware writes hardware error records in the GHES memory region, triggers
> > an NMI/interrupt, then the GHES driver goes off and grabs the error record
> > from the GHES region.
> >
> > The kernel currently maps the GHES memory region as cacheable
> > (PAGE_KERNEL) for all architectures. However, on some arm64 platforms,
> > there is a mismatch between how the kernel maps the GHES region
> > (PAGE_KERNEL) and how the firmware maps it (EFI_MEMORY_UC, ie.
> > uncacheable), leading to the possibility of the kernel GHES driver
> > reading stale data from the cache when it receives the interrupt.
> >
> > With stale data being read, the kernel is unaware there is new hardware
> > error to be handled when there actually is; this may lead to further damage
> > in various scenarios, such as error propagation caused data corruption.
> > If uncorrected error (such as double bit ECC error) happened in memory
> > operation and if the kernel is unaware of such event happening, errorneous
> > data may be propagated to the disk.
> >
> > Instead GHES memory region should be mapped with page protection type
> > according to what is returned from arch_apei_get_mem_attribute().
> >
> > Reviewed-by: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
> > Acked-by: Borislav Petkov <bp-l3A5Bk7waGM@public.gmane.org>
> > Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> > ---
> > drivers/acpi/apei/ghes.c | 10 +++++++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
>
> This patch message looks fine to me. Ingo?
Looks good to me too!
Thanks,
Ingo
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: Matt Fleming <matt@codeblueprint.co.uk>
Cc: "Jonathan (Zhixiong) Zhang" <zjzhang@codeaurora.org>,
Will Deacon <will.deacon@arm.com>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org,
Matt Fleming <matt.fleming@intel.com>,
Borislav Petkov <bp@suse.de>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Catalin Marinas <Catalin.Marinas@arm.com>
Subject: Re: [PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory
Date: Fri, 4 Sep 2015 13:36:00 +0200 [thread overview]
Message-ID: <20150904113559.GA21396@gmail.com> (raw)
In-Reply-To: <20150904112820.GB2737@codeblueprint.co.uk>
* Matt Fleming <matt@codeblueprint.co.uk> wrote:
> On Tue, 25 Aug, at 10:27:22AM, Jonathan (Zhixiong) Zhang wrote:
> > From: "Jonathan (Zhixiong) Zhang" <zjzhang@codeaurora.org>
> >
> > If the ACPI APEI firmware handles hardware error first (called "firmware
> > first handling"), the firmware updates the GHES memory region with hardware
> > error record (called "generic hardware error record"). Essentially the
> > firmware writes hardware error records in the GHES memory region, triggers
> > an NMI/interrupt, then the GHES driver goes off and grabs the error record
> > from the GHES region.
> >
> > The kernel currently maps the GHES memory region as cacheable
> > (PAGE_KERNEL) for all architectures. However, on some arm64 platforms,
> > there is a mismatch between how the kernel maps the GHES region
> > (PAGE_KERNEL) and how the firmware maps it (EFI_MEMORY_UC, ie.
> > uncacheable), leading to the possibility of the kernel GHES driver
> > reading stale data from the cache when it receives the interrupt.
> >
> > With stale data being read, the kernel is unaware there is new hardware
> > error to be handled when there actually is; this may lead to further damage
> > in various scenarios, such as error propagation caused data corruption.
> > If uncorrected error (such as double bit ECC error) happened in memory
> > operation and if the kernel is unaware of such event happening, errorneous
> > data may be propagated to the disk.
> >
> > Instead GHES memory region should be mapped with page protection type
> > according to what is returned from arch_apei_get_mem_attribute().
> >
> > Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk>
> > Acked-by: Borislav Petkov <bp@suse.de>
> > Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
> > ---
> > drivers/acpi/apei/ghes.c | 10 +++++++---
> > 1 file changed, 7 insertions(+), 3 deletions(-)
>
> This patch message looks fine to me. Ingo?
Looks good to me too!
Thanks,
Ingo
next prev parent reply other threads:[~2015-09-04 11:36 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-25 17:27 [PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory Jonathan (Zhixiong) Zhang
2015-08-25 17:27 ` Jonathan (Zhixiong) Zhang
[not found] ` <1440523642-31373-1-git-send-email-zjzhang-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-09-04 11:28 ` Matt Fleming
2015-09-04 11:28 ` Matt Fleming
[not found] ` <20150904112820.GB2737-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2015-09-04 11:36 ` Ingo Molnar [this message]
2015-09-04 11:36 ` Ingo Molnar
-- strict thread matches above, loose matches on Subject: below --
2015-09-04 13:11 [GIT PULL 0/2] EFI changes for v4.3 (part two) Matt Fleming
[not found] ` <1441372302-23242-1-git-send-email-matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2015-09-04 13:11 ` [PATCH 2/2] acpi, apei: Use appropriate pgprot_t to map GHES memory Matt Fleming
2015-09-04 13:11 ` Matt Fleming
2015-08-24 18:25 [PATCH 2/2] acpi, apei: use " Jonathan (Zhixiong) Zhang
2015-08-24 18:25 ` Jonathan (Zhixiong) Zhang
2015-08-14 22:37 [PATCH V2 1/2] arm64: apei: implement arch_apei_get_mem_attributes() Jonathan (Zhixiong) Zhang
2015-08-14 22:37 ` [PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory Jonathan (Zhixiong) Zhang
[not found] ` <1439591850-29002-2-git-send-email-zjzhang-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-08-17 13:13 ` Matt Fleming
2015-08-17 13:13 ` Matt Fleming
[not found] ` <20150817131357.GB3233-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2015-08-17 21:10 ` Zhang, Jonathan Zhixiong
2015-08-17 21:10 ` Zhang, Jonathan Zhixiong
2015-08-22 9:24 ` Ingo Molnar
2015-08-22 9:24 ` Ingo Molnar
[not found] ` <20150822092429.GB18233-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-08-24 18:22 ` Zhang, Jonathan Zhixiong
2015-08-24 18:22 ` Zhang, Jonathan Zhixiong
[not found] ` <55DB60FA.8050406-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2015-08-25 8:59 ` Ingo Molnar
2015-08-25 8:59 ` Ingo Molnar
[not found] ` <20150825085923.GA22414-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-08-25 17:30 ` Zhang, Jonathan Zhixiong
2015-08-25 17:30 ` Zhang, Jonathan Zhixiong
2015-08-12 16:17 [GIT PULL 0/2] EFI changes for v4.3 (part two) Matt Fleming
2015-08-12 16:17 ` [PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory Matt Fleming
[not found] ` <1439396234-22863-3-git-send-email-matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2015-08-13 8:19 ` Ingo Molnar
2015-08-13 8:19 ` Ingo Molnar
[not found] ` <20150813081917.GA14610-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-08-13 9:24 ` Matt Fleming
2015-08-13 9:24 ` Matt Fleming
[not found] ` <20150813092432.GA2797-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2015-08-13 11:14 ` Will Deacon
2015-08-13 11:14 ` Will Deacon
[not found] ` <20150813111422.GE10280-5wv7dgnIgG8@public.gmane.org>
2015-08-14 19:09 ` Zhang, Jonathan Zhixiong
2015-08-14 19:09 ` Zhang, Jonathan Zhixiong
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=20150904113559.GA21396@gmail.com \
--to=mingo-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
--cc=Catalin.Marinas-5wv7dgnIgG8@public.gmane.org \
--cc=ard.biesheuvel-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=bp-l3A5Bk7waGM@public.gmane.org \
--cc=hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org \
--cc=matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@public.gmane.org \
--cc=zjzhang-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
/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: link
Be 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.