Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1213197 > unrolled thread

[PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory

Back to article view | Back to linux.kernel

Contents

  [PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory "Jonathan (Zhixiong) Zhang" <zjzhang@codeaurora.org> - 2015-08-25 19:30 +0200
    Re: [PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES  memory Matt Fleming <matt@codeblueprint.co.uk> - 2015-09-04 13:30 +0200
      Re: [PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES  memory Ingo Molnar <mingo@kernel.org> - 2015-09-04 13:40 +0200

#1213197 — [PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory

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(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 23981ac1c6c2..3dd9c462d22a 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -157,11 +157,15 @@ static void __iomem *ghes_ioremap_pfn_nmi(u64 pfn)
 
 static void __iomem *ghes_ioremap_pfn_irq(u64 pfn)
 {
-	unsigned long vaddr;
+	unsigned long vaddr, paddr;
+	pgprot_t prot;
 
 	vaddr = (unsigned long)GHES_IOREMAP_IRQ_PAGE(ghes_ioremap_area->addr);
-	ioremap_page_range(vaddr, vaddr + PAGE_SIZE,
-			   pfn << PAGE_SHIFT, PAGE_KERNEL);
+
+	paddr = pfn << PAGE_SHIFT;
+	prot = arch_apei_get_mem_attribute(paddr);
+
+	ioremap_page_range(vaddr, vaddr + PAGE_SIZE, paddr, prot);
 
 	return (void __iomem *)vaddr;
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1218839 — Re: [PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory

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?

-- 
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1218848 — Re: [PATCH 2/2] acpi, apei: use appropriate pgprot_t to map GHES memory

* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web