linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com>
To: linuxppc-dev <linuxppc-dev@ozlabs.org>
Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
	kernelfans@gmail.com,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Ananth Narayan <ananth@in.ibm.com>,
	Hari Bathini <hbathini@linux.vnet.ibm.com>,
	Nathan Fontenot <nfont@linux.vnet.ibm.com>,
	Anshuman Khandual <khandual@linux.vnet.ibm.com>
Subject: [PATCH v4 7/7] powerpc/fadump: Do not allow hot-remove memory from fadump reserved area.
Date: Fri, 20 Apr 2018 10:35:08 +0530	[thread overview]
Message-ID: <152420070863.31037.11093621382553645534.stgit@jupiter.in.ibm.com> (raw)
In-Reply-To: <152420062000.31037.770773018944092449.stgit@jupiter.in.ibm.com>

From: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>

For fadump to work successfully there should not be any holes in reserved
memory ranges where kernel has asked firmware to move the content of old
kernel memory in event of crash. But this memory area is currently not
protected from hot-remove operations. Hence, fadump service can fail to
re-register after the hot-remove operation, if hot-removed memory belongs
to fadump reserved region. To avoid this make sure that memory from fadump
reserved area is not hot-removable if fadump is registered.

However, if user still wants to remove that memory, he can do so by
manually stopping fadump service before hot-remove operation.

Signed-off-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
---
 arch/powerpc/include/asm/fadump.h               |    2 +-
 arch/powerpc/kernel/fadump.c                    |   10 ++++++++--
 arch/powerpc/platforms/pseries/hotplug-memory.c |    7 +++++--
 3 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/include/asm/fadump.h b/arch/powerpc/include/asm/fadump.h
index 03d5140a6f0d..5c0a88821ae9 100644
--- a/arch/powerpc/include/asm/fadump.h
+++ b/arch/powerpc/include/asm/fadump.h
@@ -212,7 +212,7 @@ struct fad_crash_memory_ranges {
 	unsigned long long	size;
 };
 
-extern int is_fadump_boot_memory_area(u64 addr, ulong size);
+extern int is_fadump_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 4884ab796f4a..2fda1e4a6318 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -162,13 +162,19 @@ int __init early_init_dt_scan_fw_dump(unsigned long node,
 
 /*
  * If fadump is registered, check if the memory provided
- * falls within boot memory area.
+ * falls within boot memory area and reserved memory area.
  */
-int is_fadump_boot_memory_area(u64 addr, ulong size)
+int is_fadump_memory_area(u64 addr, ulong size)
 {
+	u64 d_start = fw_dump.reserve_dump_area_start;
+	u64 d_end = d_start + fw_dump.reserve_dump_area_size;
+
 	if (!fw_dump.dump_registered)
 		return 0;
 
+	if (((addr + size) > d_start) && (addr <= d_end))
+		return 1;
+
 	return (addr + size) > RMA_START && addr <= fw_dump.boot_memory_size;
 }
 
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
index c1578f54c626..e4c658cda3a7 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -389,8 +389,11 @@ static bool lmb_is_removable(struct drmem_lmb *lmb)
 	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))
+	/*
+	 * Don't hot-remove memory that falls in fadump boot memory area
+	 * and memory that is reserved for capturing old kernel memory.
+	 */
+	if (is_fadump_memory_area(phys_addr, block_sz))
 		return false;
 #endif
 

      parent reply	other threads:[~2018-04-20  5:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-20  5:04 [PATCH v4 0/7] powerpc/fadump: Improvements and fixes for firmware-assisted dump Mahesh J Salgaonkar
2018-04-20  5:04 ` [PATCH v4 1/7] powerpc/fadump: Move the metadata region to start of the reserved area Mahesh J Salgaonkar
2018-04-22  1:58   ` Nicholas Piggin
2018-04-23  5:16     ` Mahesh Jagannath Salgaonkar
2018-04-20  5:04 ` [PATCH v4 2/7] powerpc/fadump: Update documentation to reflect the metadata region movement Mahesh J Salgaonkar
2018-04-20  5:04 ` [PATCH v4 3/7] powerpc/fadump: un-register fadump on kexec path Mahesh J Salgaonkar
2018-04-22  1:58   ` Nicholas Piggin
2018-04-23  5:17     ` Mahesh Jagannath Salgaonkar
2018-04-20  5:04 ` [PATCH v4 4/7] powerpc/fadump: Reservationless firmware assisted dump Mahesh J Salgaonkar
2018-04-23 12:53   ` Hari Bathini
2018-04-20  5:04 ` [PATCH v4 5/7] powerpc/fadump: Update documentation to reflect CMA reservation Mahesh J Salgaonkar
2018-04-20  5:05 ` [PATCH v4 6/7] powerpc/fadump: throw proper error message on fadump registration failure Mahesh J Salgaonkar
2018-04-20  5:05 ` Mahesh J Salgaonkar [this message]

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=152420070863.31037.11093621382553645534.stgit@jupiter.in.ibm.com \
    --to=mahesh@linux.vnet.ibm.com \
    --cc=ananth@in.ibm.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=hbathini@linux.vnet.ibm.com \
    --cc=kernelfans@gmail.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=nfont@linux.vnet.ibm.com \
    --cc=srikar@linux.vnet.ibm.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).