From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
To: vgoyal@redhat.com
Cc: ebiederm@xmission.com, mahesh@linux.vnet.ibm.com,
schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-s390@vger.kernel.org
Subject: [RFC][patch 1/2] kdump: Add infrastructure for unmapping crashkernel memory
Date: Thu, 08 Sep 2011 15:26:10 +0200 [thread overview]
Message-ID: <20110908132652.189920773@linux.vnet.ibm.com> (raw)
In-Reply-To: 20110908132609.177038405@linux.vnet.ibm.com
[-- Attachment #1: s390-kdump-common-crash_map_pages.patch --]
[-- Type: text/plain, Size: 3245 bytes --]
From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
This patch introduces a mechanism that allows architecture backends to
remove page tables for the crashkernel memory. This can protect the loaded
kdump kernel from being overwritten by broken kernel code.
A new function crash_map_pages() is added that can be implemented by
architecture code. This function has the following syntax:
void crash_map_pages(int enable);
"enable" can be 0 for removing or 1 for adding page tables. The function is
called before and after the crashkernel segments are loaded. It is also
called in crash_shrink_memory() to create new page tables when the
crashkernel memory size is reduced.
To support architectures that have large pages this patch also introduces
a new define KEXEC_CRASH_MEM_ALIGN. The crashkernel start and size must
always be aligned with KEXEC_CRASH_MEM_ALIGN.
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
---
include/linux/kexec.h | 5 +++++
kernel/kexec.c | 16 ++++++++++++++--
2 files changed, 19 insertions(+), 2 deletions(-)
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -37,6 +37,10 @@
#define KEXEC_CRASH_CONTROL_MEMORY_LIMIT KEXEC_CONTROL_MEMORY_LIMIT
#endif
+#ifndef KEXEC_CRASH_MEM_ALIGN
+#define KEXEC_CRASH_MEM_ALIGN PAGE_SIZE
+#endif
+
#define KEXEC_NOTE_HEAD_BYTES ALIGN(sizeof(struct elf_note), 4)
#define KEXEC_CORE_NOTE_NAME "CORE"
#define KEXEC_CORE_NOTE_NAME_BYTES ALIGN(sizeof(KEXEC_CORE_NOTE_NAME), 4)
@@ -133,6 +137,7 @@ extern void crash_kexec(struct pt_regs *
int kexec_should_crash(struct task_struct *);
void crash_save_cpu(struct pt_regs *regs, int cpu);
void crash_save_vmcoreinfo(void);
+void crash_map_pages(int enable);
void arch_crash_save_vmcoreinfo(void);
void vmcoreinfo_append_str(const char *fmt, ...)
__attribute__ ((format (printf, 1, 2)));
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -999,6 +999,7 @@ SYSCALL_DEFINE4(kexec_load, unsigned lon
kimage_free(xchg(&kexec_crash_image, NULL));
result = kimage_crash_alloc(&image, entry,
nr_segments, segments);
+ crash_map_pages(1);
}
if (result)
goto out;
@@ -1015,6 +1016,8 @@ SYSCALL_DEFINE4(kexec_load, unsigned lon
goto out;
}
kimage_terminate(image);
+ if (flags & KEXEC_ON_CRASH)
+ crash_map_pages(0);
}
/* Install the new kernel, and Uninstall the old */
image = xchg(dest_image, image);
@@ -1026,6 +1029,13 @@ out:
return result;
}
+/*
+ * provide an empty default implementation here -- architecture
+ * code may override this
+ */
+void __weak crash_map_pages(int enable)
+{}
+
#ifdef CONFIG_COMPAT
asmlinkage long compat_sys_kexec_load(unsigned long entry,
unsigned long nr_segments,
@@ -1134,14 +1144,16 @@ int crash_shrink_memory(unsigned long ne
goto unlock;
}
- start = roundup(start, PAGE_SIZE);
- end = roundup(start + new_size, PAGE_SIZE);
+ start = roundup(start, KEXEC_CRASH_MEM_ALIGN);
+ end = roundup(start + new_size, KEXEC_CRASH_MEM_ALIGN);
+ crash_map_pages(1);
crash_free_reserved_phys_range(end, crashk_res.end);
if ((start == end) && (crashk_res.parent != NULL))
release_resource(&crashk_res);
crashk_res.end = end - 1;
+ crash_map_pages(0);
unlock:
mutex_unlock(&kexec_mutex);
next prev parent reply other threads:[~2011-09-08 13:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-08 13:26 [RFC][patch 0/2] kdump: Allow removal of page tables for crashkernel memory Michael Holzheu
2011-09-08 13:26 ` Michael Holzheu [this message]
2011-09-09 18:23 ` [RFC][patch 1/2] kdump: Add infrastructure for unmapping " Vivek Goyal
2011-09-12 15:55 ` Michael Holzheu
2011-09-13 13:11 ` Vivek Goyal
2011-09-09 19:30 ` Vivek Goyal
2011-09-08 13:26 ` [RFC][patch 2/2] s390: Add architecture code " Michael Holzheu
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=20110908132652.189920773@linux.vnet.ibm.com \
--to=holzheu@linux.vnet.ibm.com \
--cc=ebiederm@xmission.com \
--cc=heiko.carstens@de.ibm.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mahesh@linux.vnet.ibm.com \
--cc=schwidefsky@de.ibm.com \
--cc=vgoyal@redhat.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).