[PATCH v2 4/4] arm64: acpi: fix alignment fault in accessing ACPI

2018-06-19 Thread AKASHI Takahiro
This is a fix against the issue that crash dump kernel may hang up
during booting, which can happen on any ACPI-based system with "ACPI
Reclaim Memory."

(kernel messages after panic kicked off kdump)
   (snip...)
Bye!
   (snip...)
ACPI: Core revision 20170728
pud=2e7d0003, *pmd=2e7c0003, *pte=00e839710707
Internal error: Oops: 9621 [#1] SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1
task: 08d05180 task.stack: 08cc
PC is at acpi_ns_lookup+0x25c/0x3c0
LR is at acpi_ds_load1_begin_op+0xa4/0x294
   (snip...)
Process swapper/0 (pid: 0, stack limit = 0x08cc)
Call trace:
   (snip...)
[] acpi_ns_lookup+0x25c/0x3c0
[] acpi_ds_load1_begin_op+0xa4/0x294
[] acpi_ps_build_named_op+0xc4/0x198
[] acpi_ps_create_op+0x14c/0x270
[] acpi_ps_parse_loop+0x188/0x5c8
[] acpi_ps_parse_aml+0xb0/0x2b8
[] acpi_ns_one_complete_parse+0x144/0x184
[] acpi_ns_parse_table+0x48/0x68
[] acpi_ns_load_table+0x4c/0xdc
[] acpi_tb_load_namespace+0xe4/0x264
[] acpi_load_tables+0x48/0xc0
[] acpi_early_init+0x9c/0xd0
[] start_kernel+0x3b4/0x43c
Code: b9008fb9 2a000318 36380054 32190318 (b94002c0)
---[ end trace c46ed37f9651c58e ]---
Kernel panic - not syncing: Fatal exception
Rebooting in 10 seconds..

(diagnosis)
* This fault is a data abort, alignment fault (ESR=0x9621)
  during reading out ACPI table.
* Initial ACPI tables are normally stored in system ram and marked as
  "ACPI Reclaim memory" by the firmware.
* After the commit f56ab9a5b73c ("efi/arm: Don't mark ACPI reclaim
  memory as MEMBLOCK_NOMAP"), those regions are differently handled
  as they are "memblock-reserved", without NOMAP bit.
* So they are now excluded from device tree's "usable-memory-range"
  which kexec-tools determines based on a current view of /proc/iomem.
* When crash dump kernel boots up, it tries to accesses ACPI tables by
  mapping them with ioremap(), not ioremap_cache(), in acpi_os_ioremap()
  since they are no longer part of mapped system ram.
* Given that ACPI accessor/helper functions are compiled in without
  unaligned access support (ACPI_MISALIGNMENT_NOT_SUPPORTED),
  any unaligned access to ACPI tables can cause a fatal panic.

With this patch, acpi_os_ioremap() always honors memory attribute
information provided by the firmware (EFI) and retaining cacheability
allows the kernel safe access to ACPI tables.

Signed-off-by: AKASHI Takahiro 
Suggested-by: James Morse 
Suggested-by: Ard Biesheuvel 
Reported-by and Tested-by: Bhupesh Sharma 
---
 arch/arm64/include/asm/acpi.h | 23 ---
 arch/arm64/kernel/acpi.c  | 11 +++
 2 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 0db62a4cbce2..68bc18cb2b85 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -12,10 +12,12 @@
 #ifndef _ASM_ACPI_H
 #define _ASM_ACPI_H
 
+#include 
 #include 
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -29,18 +31,22 @@
 
 /* Basic configuration for ACPI */
 #ifdef CONFIG_ACPI
+pgprot_t __acpi_get_mem_attribute(phys_addr_t addr);
+
 /* ACPI table mapping after acpi_permanent_mmap is set */
 static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
acpi_size size)
 {
+   /* For normal memory we already have a cacheable mapping. */
+   if (memblock_is_map_memory(phys))
+   return (void __iomem *)__phys_to_virt(phys);
+
/*
-* EFI's reserve_regions() call adds memory with the WB attribute
-* to memblock via early_init_dt_add_memory_arch().
+* We should still honor the memory's attribute here because
+* crash dump kernel possibly excludes some ACPI (reclaim)
+* regions from memblock list.
 */
-   if (!memblock_is_memory(phys))
-   return ioremap(phys, size);
-
-   return ioremap_cache(phys, size);
+   return __ioremap(phys, size, __acpi_get_mem_attribute(phys));
 }
 #define acpi_os_ioremap acpi_os_ioremap
 
@@ -129,7 +135,10 @@ static inline const char *acpi_get_enable_method(int cpu)
  * for compatibility.
  */
 #define acpi_disable_cmcff 1
-pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
+static inline pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
+{
+   return __acpi_get_mem_attribute(addr);
+}
 #endif /* CONFIG_ACPI_APEI */
 
 #ifdef CONFIG_ACPI_NUMA
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 7b09487ff8fb..ed46dc188b22 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ 

[PATCH v2 4/4] arm64: acpi: fix alignment fault in accessing ACPI

2018-06-19 Thread AKASHI Takahiro
This is a fix against the issue that crash dump kernel may hang up
during booting, which can happen on any ACPI-based system with "ACPI
Reclaim Memory."

(kernel messages after panic kicked off kdump)
   (snip...)
Bye!
   (snip...)
ACPI: Core revision 20170728
pud=2e7d0003, *pmd=2e7c0003, *pte=00e839710707
Internal error: Oops: 9621 [#1] SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1
task: 08d05180 task.stack: 08cc
PC is at acpi_ns_lookup+0x25c/0x3c0
LR is at acpi_ds_load1_begin_op+0xa4/0x294
   (snip...)
Process swapper/0 (pid: 0, stack limit = 0x08cc)
Call trace:
   (snip...)
[] acpi_ns_lookup+0x25c/0x3c0
[] acpi_ds_load1_begin_op+0xa4/0x294
[] acpi_ps_build_named_op+0xc4/0x198
[] acpi_ps_create_op+0x14c/0x270
[] acpi_ps_parse_loop+0x188/0x5c8
[] acpi_ps_parse_aml+0xb0/0x2b8
[] acpi_ns_one_complete_parse+0x144/0x184
[] acpi_ns_parse_table+0x48/0x68
[] acpi_ns_load_table+0x4c/0xdc
[] acpi_tb_load_namespace+0xe4/0x264
[] acpi_load_tables+0x48/0xc0
[] acpi_early_init+0x9c/0xd0
[] start_kernel+0x3b4/0x43c
Code: b9008fb9 2a000318 36380054 32190318 (b94002c0)
---[ end trace c46ed37f9651c58e ]---
Kernel panic - not syncing: Fatal exception
Rebooting in 10 seconds..

(diagnosis)
* This fault is a data abort, alignment fault (ESR=0x9621)
  during reading out ACPI table.
* Initial ACPI tables are normally stored in system ram and marked as
  "ACPI Reclaim memory" by the firmware.
* After the commit f56ab9a5b73c ("efi/arm: Don't mark ACPI reclaim
  memory as MEMBLOCK_NOMAP"), those regions are differently handled
  as they are "memblock-reserved", without NOMAP bit.
* So they are now excluded from device tree's "usable-memory-range"
  which kexec-tools determines based on a current view of /proc/iomem.
* When crash dump kernel boots up, it tries to accesses ACPI tables by
  mapping them with ioremap(), not ioremap_cache(), in acpi_os_ioremap()
  since they are no longer part of mapped system ram.
* Given that ACPI accessor/helper functions are compiled in without
  unaligned access support (ACPI_MISALIGNMENT_NOT_SUPPORTED),
  any unaligned access to ACPI tables can cause a fatal panic.

With this patch, acpi_os_ioremap() always honors memory attribute
information provided by the firmware (EFI) and retaining cacheability
allows the kernel safe access to ACPI tables.

Signed-off-by: AKASHI Takahiro 
Suggested-by: James Morse 
Suggested-by: Ard Biesheuvel 
Reported-by and Tested-by: Bhupesh Sharma 
---
 arch/arm64/include/asm/acpi.h | 23 ---
 arch/arm64/kernel/acpi.c  | 11 +++
 2 files changed, 19 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 0db62a4cbce2..68bc18cb2b85 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -12,10 +12,12 @@
 #ifndef _ASM_ACPI_H
 #define _ASM_ACPI_H
 
+#include 
 #include 
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -29,18 +31,22 @@
 
 /* Basic configuration for ACPI */
 #ifdef CONFIG_ACPI
+pgprot_t __acpi_get_mem_attribute(phys_addr_t addr);
+
 /* ACPI table mapping after acpi_permanent_mmap is set */
 static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
acpi_size size)
 {
+   /* For normal memory we already have a cacheable mapping. */
+   if (memblock_is_map_memory(phys))
+   return (void __iomem *)__phys_to_virt(phys);
+
/*
-* EFI's reserve_regions() call adds memory with the WB attribute
-* to memblock via early_init_dt_add_memory_arch().
+* We should still honor the memory's attribute here because
+* crash dump kernel possibly excludes some ACPI (reclaim)
+* regions from memblock list.
 */
-   if (!memblock_is_memory(phys))
-   return ioremap(phys, size);
-
-   return ioremap_cache(phys, size);
+   return __ioremap(phys, size, __acpi_get_mem_attribute(phys));
 }
 #define acpi_os_ioremap acpi_os_ioremap
 
@@ -129,7 +135,10 @@ static inline const char *acpi_get_enable_method(int cpu)
  * for compatibility.
  */
 #define acpi_disable_cmcff 1
-pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
+static inline pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
+{
+   return __acpi_get_mem_attribute(addr);
+}
 #endif /* CONFIG_ACPI_APEI */
 
 #ifdef CONFIG_ACPI_NUMA
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 7b09487ff8fb..ed46dc188b22 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@