[PATCH v2 1/3] powerpc/fadump: avoid duplicates in crash memory ranges

Subsystems: linux for powerpc (32-bit and 64-bit), the rest

STALE3369d REVIEWED: 1 (0M)

1 review trailer.

4 messages, 2 authors, 2017-05-12 · open the first message on its own page

[PATCH v2 1/3] powerpc/fadump: avoid duplicates in crash memory ranges

From: Hari Bathini <hidden>
Date: 2017-05-11 19:23:48

fadump sets up crash memory ranges to be used for creating PT_LOAD
program headers in elfcore header. Memory chunk RMA_START through
boot memory area size is added as the first memory range because
firmware, at the time of crash, moves this memory chunk to different
location specified during fadump registration making it necessary to
create a separate program header for it with the correct offset.
This memory chunk is skipped while setting up the remaining memory
ranges. But currently, there is possibility that some of this memory
may have duplicate entries like when it is hot-removed and added
again. Ensure that no two memory ranges represent the same memory.

When 10 lmbs are hot-removed and then hot-plugged before registering
fadump, here is how the program headers in /proc/vmcore exported by
fadump look like

without this change:

  Program Headers:
    Type           Offset             VirtAddr           PhysAddr
                   FileSiz            MemSiz              Flags  Align
    NOTE           0x0000000000010000 0x0000000000000000 0x0000000000000000
                   0x0000000000001890 0x0000000000001890         0
    LOAD           0x0000000000021020 0xc000000000000000 0x0000000000000000
                   0x0000000080000000 0x0000000080000000  RWE    0
    LOAD           0x0000000080031020 0xc000000000000000 0x0000000000000000
                   0x0000000020000000 0x0000000020000000  RWE    0
    LOAD           0x00000000a0040000 0xc000000020000000 0x0000000020000000
                   0x0000000050000000 0x0000000050000000  RWE    0
    LOAD           0x00000000f0040000 0xc000000070000000 0x0000000070000000
                   0x0000000010000000 0x0000000010000000  RWE    0
    LOAD           0x0000000100040000 0xc000000100020000 0x0000000100020000
                   0x000000000ffe0000 0x000000000ffe0000  RWE    0
    LOAD           0x0000000110020000 0xc000000110000000 0x0000000110000000
                   0x00000000b0000000 0x00000000b0000000  RWE    0
    LOAD           0x00000001c0020000 0xc0000001c0000000 0x00000001c0000000
                   0x0000000080000000 0x0000000080000000  RWE    0

and with this change:

  Program Headers:
    Type           Offset             VirtAddr           PhysAddr
                   FileSiz            MemSiz              Flags  Align
    NOTE           0x0000000000010000 0x0000000000000000 0x0000000000000000
                   0x0000000000001890 0x0000000000001890         0
    LOAD           0x0000000000021020 0xc000000000000000 0x0000000000000000
                   0x0000000080000000 0x0000000080000000  RWE    0
    LOAD           0x0000000080030000 0xc000000100020000 0x0000000100020000
                   0x000000000ffe0000 0x000000000ffe0000  RWE    0
    LOAD           0x0000000090010000 0xc000000110000000 0x0000000110000000
                   0x0000000060000000 0x0000000060000000  RWE    0
    LOAD           0x00000000f0010000 0xc000000170000000 0x0000000170000000
                   0x00000000d0000000 0x00000000d0000000  RWE    0


Signed-off-by: Hari Bathini <redacted>
Reviewed-by: Mahesh J Salgaonkar <redacted>
---

Changes since v1:
* Changelog updated based on data from latest kerenl.
* Updated comment with the assumption involved.


 arch/powerpc/kernel/fadump.c |   14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 466569e..e4e1a14 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -831,8 +831,18 @@ static void fadump_setup_crash_memory_ranges(void)
 	for_each_memblock(memory, reg) {
 		start = (unsigned long long)reg->base;
 		end = start + (unsigned long long)reg->size;
-		if (start == RMA_START && end >= fw_dump.boot_memory_size)
-			start = fw_dump.boot_memory_size;
+
+		/*
+		 * skip the first memory chunk that is already added (RMA_START
+		 * through boot_memory_size). This logic needs a relook if and
+		 * when RMA_START changes to a non-zero value.
+		 */
+		if (start < fw_dump.boot_memory_size) {
+			if (end > fw_dump.boot_memory_size)
+				start = fw_dump.boot_memory_size;
+			else
+				continue;
+		}
 
 		/* add this range excluding the reserved dump area. */
 		fadump_exclude_reserved_area(start, end);

[PATCH v2 2/3] powerpc/fadump: avoid holes in boot memory area when fadump is registered

From: Hari Bathini <hidden>
Date: 2017-05-11 19:24:29

To register fadump, boot memory area - the size of low memory chunk that
is required for a kernel to boot successfully when booted with restricted
memory, is assumed to have no holes. But this memory area is currently
not protected from hot-remove operations. So, fadump could fail to
re-register after a memory hot-remove operation, if memory is removed
from boot memory area. To avoid this, ensure that memory from boot
memory area is not hot-removed when fadump is registered.

Signed-off-by: Hari Bathini <redacted>
Reviewed-by: Mahesh J Salgaonkar <redacted>
---

* No changes since v1.


 arch/powerpc/include/asm/fadump.h               |    1 +
 arch/powerpc/kernel/fadump.c                    |   12 ++++++++++++
 arch/powerpc/platforms/pseries/hotplug-memory.c |    7 +++++++
 3 files changed, 20 insertions(+)
diff --git a/arch/powerpc/include/asm/fadump.h b/arch/powerpc/include/asm/fadump.h
index 60b9108..d3e1e18 100644
--- a/arch/powerpc/include/asm/fadump.h
+++ b/arch/powerpc/include/asm/fadump.h
@@ -200,6 +200,7 @@ struct fad_crash_memory_ranges {
 	unsigned long long	size;
 };
 
+extern int is_fadump_boot_memory_area(u64 addr, ulong size);
 extern int early_init_dt_scan_fw_dump(unsigned long node,
 		const char *uname, int depth, void *data);
 extern int fadump_reserve_mem(void);
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index e4e1a14..4ba7db9 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -113,6 +113,18 @@ int __init early_init_dt_scan_fw_dump(unsigned long node,
 	return 1;
 }
 
+/*
+ * If fadump is registered, check if the memory provided
+ * falls within boot memory area.
+ */
+int is_fadump_boot_memory_area(u64 addr, ulong size)
+{
+	if (!fw_dump.dump_registered)
+		return 0;
+
+	return (addr + size) > RMA_START && addr <= fw_dump.boot_memory_size;
+}
+
 int is_fadump_active(void)
 {
 	return fw_dump.dump_active;
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
index e104c71..a186b8e 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -22,6 +22,7 @@
 #include <asm/machdep.h>
 #include <asm/prom.h>
 #include <asm/sparsemem.h>
+#include <asm/fadump.h>
 #include "pseries.h"
 
 static bool rtas_hp_event;
@@ -406,6 +407,12 @@ static bool lmb_is_removable(struct of_drconf_cell *lmb)
 	scns_per_block = block_sz / MIN_MEMORY_BLOCK_SIZE;
 	phys_addr = lmb->base_addr;
 
+#ifdef CONFIG_FA_DUMP
+	/* Don't hot-remove memory that falls in fadump boot memory area */
+	if (is_fadump_boot_memory_area(phys_addr, block_sz))
+		return false;
+#endif
+
 	for (i = 0; i < scns_per_block; i++) {
 		pfn = PFN_DOWN(phys_addr);
 		if (!pfn_present(pfn))

[PATCH v2 3/3] powerpc/fadump: provide a helpful error message

From: Hari Bathini <hidden>
Date: 2017-05-11 19:24:59

fadump fails to register when there are holes in boot memory area.
Provide a helpful error message to the user in such case.

Signed-off-by: Hari Bathini <redacted>
---

Changes since v1:
* Introducing this patch to provide better error message on failure.


 arch/powerpc/kernel/fadump.c |   36 ++++++++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index 4ba7db9..b1aaa8d 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -130,6 +130,38 @@ int is_fadump_active(void)
 	return fw_dump.dump_active;
 }
 
+/*
+ * Returns 1, if there are no holes in boot memory area,
+ * 0 otherwise.
+ */
+static int is_boot_memory_area_contiguous(void)
+{
+	struct memblock_region *reg;
+	unsigned long tstart, tend;
+	unsigned long start_pfn = PHYS_PFN(RMA_START);
+	unsigned long end_pfn = PHYS_PFN(RMA_START + fw_dump.boot_memory_size);
+	unsigned int ret = 0;
+
+	for_each_memblock(memory, reg) {
+		tstart = max(start_pfn, memblock_region_memory_base_pfn(reg));
+		tend = min(end_pfn, memblock_region_memory_end_pfn(reg));
+		if (tstart < tend) {
+			/* Memory hole from start_pfn to tstart */
+			if (tstart > start_pfn)
+				break;
+
+			if (tend == end_pfn) {
+				ret = 1;
+				break;
+			}
+
+			start_pfn = tend + 1;
+		}
+	}
+
+	return ret;
+}
+
 /* Print firmware assisted dump configurations for debugging purpose. */
 static void fadump_show_config(void)
 {
@@ -414,6 +446,10 @@ static void register_fw_dump(struct fadump_mem_struct *fdm)
 			" dump. Hardware Error(%d).\n", rc);
 		break;
 	case -3:
+		if (!is_boot_memory_area_contiguous())
+			pr_err("Can't have holes in boot memory area while "
+			       "registering fadump\n");
+
 		printk(KERN_ERR "Failed to register firmware-assisted kernel"
 			" dump. Parameter Error(%d).\n", rc);
 		break;

Re: [PATCH v2 1/3] powerpc/fadump: avoid duplicates in crash memory ranges

From: Michal Suchánek <hidden>
Date: 2017-05-12 15:01:53

On Fri, 12 May 2017 00:52:47 +0530
Hari Bathini [off-list ref] wrote:
quoted hunk
fadump sets up crash memory ranges to be used for creating PT_LOAD
program headers in elfcore header. Memory chunk RMA_START through
boot memory area size is added as the first memory range because
firmware, at the time of crash, moves this memory chunk to different
location specified during fadump registration making it necessary to
create a separate program header for it with the correct offset.
This memory chunk is skipped while setting up the remaining memory
ranges. But currently, there is possibility that some of this memory
may have duplicate entries like when it is hot-removed and added
again. Ensure that no two memory ranges represent the same memory.

When 10 lmbs are hot-removed and then hot-plugged before registering
fadump, here is how the program headers in /proc/vmcore exported by
fadump look like

without this change:

  Program Headers:
    Type           Offset             VirtAddr           PhysAddr
                   FileSiz            MemSiz              Flags  Align
    NOTE           0x0000000000010000 0x0000000000000000
0x0000000000000000 0x0000000000001890 0x0000000000001890         0
    LOAD           0x0000000000021020 0xc000000000000000
0x0000000000000000 0x0000000080000000 0x0000000080000000  RWE    0
    LOAD           0x0000000080031020 0xc000000000000000
0x0000000000000000 0x0000000020000000 0x0000000020000000  RWE    0
    LOAD           0x00000000a0040000 0xc000000020000000
0x0000000020000000 0x0000000050000000 0x0000000050000000  RWE    0
    LOAD           0x00000000f0040000 0xc000000070000000
0x0000000070000000 0x0000000010000000 0x0000000010000000  RWE    0
    LOAD           0x0000000100040000 0xc000000100020000
0x0000000100020000 0x000000000ffe0000 0x000000000ffe0000  RWE    0
    LOAD           0x0000000110020000 0xc000000110000000
0x0000000110000000 0x00000000b0000000 0x00000000b0000000  RWE    0
    LOAD           0x00000001c0020000 0xc0000001c0000000
0x00000001c0000000 0x0000000080000000 0x0000000080000000  RWE    0

and with this change:

  Program Headers:
    Type           Offset             VirtAddr           PhysAddr
                   FileSiz            MemSiz              Flags  Align
    NOTE           0x0000000000010000 0x0000000000000000
0x0000000000000000 0x0000000000001890 0x0000000000001890         0
    LOAD           0x0000000000021020 0xc000000000000000
0x0000000000000000 0x0000000080000000 0x0000000080000000  RWE    0
    LOAD           0x0000000080030000 0xc000000100020000
0x0000000100020000 0x000000000ffe0000 0x000000000ffe0000  RWE    0
    LOAD           0x0000000090010000 0xc000000110000000
0x0000000110000000 0x0000000060000000 0x0000000060000000  RWE    0
    LOAD           0x00000000f0010000 0xc000000170000000
0x0000000170000000 0x00000000d0000000 0x00000000d0000000  RWE    0


Signed-off-by: Hari Bathini <redacted>
Reviewed-by: Mahesh J Salgaonkar <redacted>
---

Changes since v1:
* Changelog updated based on data from latest kerenl.
* Updated comment with the assumption involved.


 arch/powerpc/kernel/fadump.c |   14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/fadump.c
b/arch/powerpc/kernel/fadump.c index 466569e..e4e1a14 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -831,8 +831,18 @@ static void
fadump_setup_crash_memory_ranges(void) for_each_memblock(memory, reg)
{ start = (unsigned long long)reg->base;
 		end = start + (unsigned long long)reg->size;
-		if (start == RMA_START && end >=
fw_dump.boot_memory_size)
-			start = fw_dump.boot_memory_size;
+
+		/*
+		 * skip the first memory chunk that is already added
(RMA_START
+		 * through boot_memory_size). This logic needs a
relook if and
+		 * when RMA_START changes to a non-zero value.
+		 */
BUILD_BUG_ON(RMA_START)?

Thanks

Michal
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help