Re: [patch v2 2/2] s390: Add architecture code for unmapping crashkernel memory
On Tue, 13 Sep 2011 15:26:37 +0200
Michael Holzheu wrote:
> From: Michael Holzheu
>
> This patch implements the crash_map_pages() function for s390.
> KEXEC_CRASH_MEM_ALIGN is set to HPAGE_SIZE, in order to support
> kernel mappings that use large pages.
>
> Signed-off-by: Michael Holzheu
> ---
> arch/s390/include/asm/kexec.h|3 +++
> arch/s390/kernel/machine_kexec.c | 31 +++
> arch/s390/kernel/setup.c | 10 ++
> 3 files changed, 40 insertions(+), 4 deletions(-)
>
> --- a/arch/s390/include/asm/kexec.h
> +++ b/arch/s390/include/asm/kexec.h
> @@ -36,6 +36,9 @@
> /* Allocate one page for the pdp and the second for the code */
> #define KEXEC_CONTROL_PAGE_SIZE 4096
>
> +/* Alignment of crashkernel memory */
> +#define KEXEC_CRASH_MEM_ALIGN HPAGE_SIZE
Why not make this unconditional, for all architectures which support
hugepages? ie:
#ifdef HPAGE_SIZE
#define KEXEC_CRASH_MEM_ALIGN HPAGE_SIZE
#else
#define KEXEC_CRASH_MEM_ALIGN PAGE_SIZE
#endif
in include/linux/kexec.h?
IOW, what are the compromises here?
Also, does s390 support CONFIG_HUGETLB_PAGE=n? If so, does the use of
HPAGE_SIZE still make sense? Does it compile?
> /* The native architecture */
> #define KEXEC_ARCH KEXEC_ARCH_S390
>
> --- a/arch/s390/kernel/machine_kexec.c
> +++ b/arch/s390/kernel/machine_kexec.c
> @@ -243,6 +243,37 @@ static void __machine_kdump(void *image)
> #endif
>
> /*
> + * Map or unmap crashkernel memory
> + */
> +static void crash_map_pages(int enable)
> +{
> + unsigned long size = crashk_res.end - crashk_res.start + 1;
resource_size().
> + BUG_ON(crashk_res.start % KEXEC_CRASH_MEM_ALIGN ||
> +size % KEXEC_CRASH_MEM_ALIGN);
> + if (enable)
> + vmem_add_mapping(crashk_res.start, size);
> + else
> + vmem_remove_mapping(crashk_res.start, size);
> +}
>
> ...
>
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: vmcore_init() failure using uImage on fsl_booke
On Tue, Sep 13, 2011 at 4:33 PM, Dennis Flynn wrote: > Reserved crash kernel memory: crashkernel=256M@512 I assume this is 512M? > Reading 16 bytes from address 0x2086E000 within /dev/oldmem > 00 00 00 00 00 00 00 00 > Warning: Core image elf header not found > Kdump: vmcore not initialized > > Here's the crash kernel bootline showing the elfcorehdr argument passed to > the crash kernel. > > Kernel command line: irqpoll maxcpus=1 reset_devices boot_mode=crash > root=/dev/nfs nfsroot=127.3.252.1:/var/export/hitchhiker-6kn/current/rootfs > ip=127.3.10.1:127.3.252.1:127.3.252.1:255.255.0.0:hitchhiker-6kn:eth0:off > rbn_net_dev=eth0 console=ttyS0,115200 dump_type=kernel dump_server=0.0.0.0 > dump_server_port= hwether=x board_name=wolf_lc slot_number=255 > elfcorehdr=532920K savemaxmem=2048M > > To help me debug all of this I added some debug prints to the powerpc kexec > code (default_machine_kexec()) so I could verify the kernel kimage and memory > segment contents. See below. > > Bye! > Calling reboot_code_buffer (vaddr:0xe086f000): page_list=0x0004, > reboot_code_buffer_phys=0x2086f000, start=0x2fffa724 > > Dumping kimage @ 0xdfbdf800 > head: 0x0004 > entry: 0xdfbdf800 > last_entry: 0xdfbdf800 > destination: 0x > start: 0x2fffa724 > control_code_page: 0xc0c97de0 > swap_page: 0x (null) > control_page: 0x2086 > type: 0x0001 > preserve_context: 0x > nr_segments = 5 > segment[0].buf = 48831008 > segment[0].bufsz = 75d640 > segment[0].mem = 0x2000 > segment[0].memsz = 85e000 > segment[1].buf = 1007d988 > segment[1].bufsz = 1 > segment[1].mem = 0x2085e000 > segment[1].memsz = 1 > segment[2].buf = 1007d350 > segment[2].bufsz = 400 > segment[2].mem = 0x2086e000 > segment[2].memsz = 1000 It appears to have allocated a segment at this address. Can you try adding debug statements to exec to see the contents of this segment? I suspect kexec is loading nothing since it does not have an ELF header to load for the uImage case. -M ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
vmcore_init() failure using uImage on fsl_booke
Hi, I am seeing a problem with the kdump kernel running on my Freescale mpc8536 based board. Specifically when the crash kernel boots after a forced panic, vmcore fails to initialize. The following errors are displayed by vmcore_init() Warning: Core image elf header not found Kdump: vmcore not initialized I only see this problem when loading a uImage-ppc image type. The problem does not occur when loading a elf-ppc image type (i.e. vmlinux). I am using kernel version 2.6.39 and kexec-tools version as of 6/16/2011. The problem seems to one of vmcore_init not being able to locate the ELF image header within the old kernel (/dev/oldmem). See additional details below. Reserved crash kernel memory: crashkernel=256M@512 uImage file built as below to match the reserved memory area: lxapp-2:lc$ mkimage -A ppc -O linux -T kernel -C gzip -a 0x2000 -e 0x2000 -n Linux-2.6.39.3-495-g56d1401-dirty -d vmlinux.bin.gz uImage.kdump Image Name: Linux-2.6.39.3-495-g56d1401-dirt Created: Mon Sep 12 14:06:23 2011 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:4842545 Bytes = 4729.05 kB = 4.62 MB Load Address: 2000 Entry Point: 2000 After loading the crash kernel (uImage.kdump) I then force a kernel panic and the crash kernel is invoked as expected. However it appears as though the crash kernel is having trouble accessing some of the memory of the original kernel (/dev/oldmem). Specifically the test for the ELF header magic number is failing during vmcore_init(). As a result /proc/vmcore is not available within the crash kernel and hence I cannot create a dump of the original kernel. Here's the errors I am seeing. Note I have augmented the debug prints slightly to verify the inability to see the kernel image elf header. Reading 16 bytes from address 0x2086E000 within /dev/oldmem 00 00 00 00 00 00 00 00 Warning: Core image elf header not found Kdump: vmcore not initialized Here's the crash kernel bootline showing the elfcorehdr argument passed to the crash kernel. Kernel command line: irqpoll maxcpus=1 reset_devices boot_mode=crash root=/dev/nfs nfsroot=127.3.252.1:/var/export/hitchhiker-6kn/current/rootfs ip=127.3.10.1:127.3.252.1:127.3.252.1:255.255.0.0:hitchhiker-6kn:eth0:off rbn_net_dev=eth0 console=ttyS0,115200 dump_type=kernel dump_server=0.0.0.0 dump_server_port= hwether=x board_name=wolf_lc slot_number=255 elfcorehdr=532920K savemaxmem=2048M To help me debug all of this I added some debug prints to the powerpc kexec code (default_machine_kexec()) so I could verify the kernel kimage and memory segment contents. See below. Bye! Calling reboot_code_buffer (vaddr:0xe086f000): page_list=0x0004, reboot_code_buffer_phys=0x2086f000, start=0x2fffa724 Dumping kimage @ 0xdfbdf800 head: 0x0004 entry: 0xdfbdf800 last_entry: 0xdfbdf800 destination: 0x start: 0x2fffa724 control_code_page: 0xc0c97de0 swap_page: 0x (null) control_page: 0x2086 type: 0x0001 preserve_context: 0x nr_segments = 5 segment[0].buf = 48831008 segment[0].bufsz = 75d640 segment[0].mem = 0x2000 segment[0].memsz = 85e000 segment[1].buf = 1007d988 segment[1].bufsz = 1 segment[1].mem = 0x2085e000 segment[1].memsz = 1 segment[2].buf = 1007d350 segment[2].bufsz = 400 segment[2].mem = 0x2086e000 segment[2].memsz = 1000 segment[3].buf = 10093fa8 segment[3].bufsz = 2b62 segment[3].mem = 0x217fd000 segment[3].memsz = 3000 segment[4].buf = 1008e380 segment[4].bufsz = 5c20 segment[4].mem = 0x2fffa000 segment[4].memsz = 6000 Thanks for any help, Dennis ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: Kexec on P1020 - "Can't add kernel to addr 0x00000000"
On Fri, Sep 9, 2011 at 9:36 AM, john hagen wrote: > Hello, > > I'm trying to make use of kexec on a couple of boards, a P1020rdb and > a custom P1011 board. My first attempts seem to report this "Can't add > kernel to addr 0x". What is kexec trying to tell me? Looking > for a pointer here, thanks. > > JH > > [root@P1020RDB jlhagen]# cat /proc/cmdline > root=/dev/ram rw crashkernel=128M@32M console=ttyS0,115200 ramdisk_size=60 > > [root@P1020RDB jlhagen]# dmesg | grep -i reser > Reserving 128MB of memory at 32MB for crashkernel (System RAM: 512MB) > > [root@P1020RDB jlhagen]# ls -al /proc/device-tree/memory/ > dr-xr-xr-x 2 root root 0 Jan 1 00:11 . > dr-xr-xr-x 10 root root 0 Jan 1 00:11 .. > -r--r--r-- 1 root root 7 Jan 1 00:11 device_type > -r--r--r-- 1 root root 7 Jan 1 00:11 name > -r--r--r-- 1 root root 16 Jan 1 00:11 reg > > [root@P1020RDB jlhagen]# ./kexec -t uImage-ppc -l uImage-3.0.3 > --dtb=./p1020rdb.dtb > kernel: 0x4802f008 kernel_size: 24bda4 > Can't add kernel to addr 0x len 8182336 > Cannot load uImage-3.0.3 This seems wrong since if you are just kexec'ing it does not matter what the load address is. Something else is setting an overlapping region that is conflicting or there is an issue. Can you try with a vmlinuxx or recompile with DEBUG? > [root@P1020RDB jlhagen]# ./kexec -p -t uImage-ppc uImage-3.0.3 > kernel: 0x4802f008 kernel_size: 24bda4 > Can't add kernel to addr 0x len 8182336 > Cannot load uImage-3.0.3 You uImage has a hard coded address of 0x0 for the kernel image. It's saying I can't load the kexec kernel here since it's not in your crashkernel memory region. Did you run a custom mkimage to modify the load/entry address of your kexec uImage for kdump? -M ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [patch v2 1/2] kdump: Add infrastructure for unmapping crashkernel memory
On Tue, Sep 13, 2011 at 03:26:36PM +0200, Michael Holzheu wrote:
> From: Michael Holzheu
>
> 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. Two new
> functions crash_map_reserved_pages() and crash_unmap_reserved_pages() are
> added that can be implemented by architecture code. The
> crash_map_reserved_pages() function is called before and
> crash_unmap_reserved_pages() after the crashkernel segments are loaded. The
> functions are also called in crash_shrink_memory() to create/remove 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
Looks reasonable conceptually. Hence...
Acked-by: Vivek Goyal
Thanks
Vivek
> ---
> include/linux/kexec.h |6 ++
> kernel/kexec.c| 21 +++--
> 2 files changed, 25 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,8 @@ 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_reserved_pages(void);
> +void crash_unmap_reserved_pages(void);
> 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_reserved_pages();
> }
> 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_unmap_reserved_pages();
> }
> /* Install the new kernel, and Uninstall the old */
> image = xchg(dest_image, image);
> @@ -1026,6 +1029,18 @@ out:
> return result;
> }
>
> +/*
> + * Add and remove page tables for crashkernel memory
> + *
> + * Provide an empty default implementation here -- architecture
> + * code may override this
> + */
> +void __weak crash_map_reserved_pages(void)
> +{}
> +
> +void __weak crash_unmap_reserved_pages(void)
> +{}
> +
> #ifdef CONFIG_COMPAT
> asmlinkage long compat_sys_kexec_load(unsigned long entry,
> unsigned long nr_segments,
> @@ -1134,14 +1149,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_reserved_pages();
> 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_unmap_reserved_pages();
>
> unlock:
> mutex_unlock(&kexec_mutex);
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[patch v2 2/2] s390: Add architecture code for unmapping crashkernel memory
From: Michael Holzheu
This patch implements the crash_map_pages() function for s390.
KEXEC_CRASH_MEM_ALIGN is set to HPAGE_SIZE, in order to support
kernel mappings that use large pages.
Signed-off-by: Michael Holzheu
---
arch/s390/include/asm/kexec.h|3 +++
arch/s390/kernel/machine_kexec.c | 31 +++
arch/s390/kernel/setup.c | 10 ++
3 files changed, 40 insertions(+), 4 deletions(-)
--- a/arch/s390/include/asm/kexec.h
+++ b/arch/s390/include/asm/kexec.h
@@ -36,6 +36,9 @@
/* Allocate one page for the pdp and the second for the code */
#define KEXEC_CONTROL_PAGE_SIZE 4096
+/* Alignment of crashkernel memory */
+#define KEXEC_CRASH_MEM_ALIGN HPAGE_SIZE
+
/* The native architecture */
#define KEXEC_ARCH KEXEC_ARCH_S390
--- a/arch/s390/kernel/machine_kexec.c
+++ b/arch/s390/kernel/machine_kexec.c
@@ -243,6 +243,37 @@ static void __machine_kdump(void *image)
#endif
/*
+ * Map or unmap crashkernel memory
+ */
+static void crash_map_pages(int enable)
+{
+ unsigned long size = crashk_res.end - crashk_res.start + 1;
+
+ BUG_ON(crashk_res.start % KEXEC_CRASH_MEM_ALIGN ||
+ size % KEXEC_CRASH_MEM_ALIGN);
+ if (enable)
+ vmem_add_mapping(crashk_res.start, size);
+ else
+ vmem_remove_mapping(crashk_res.start, size);
+}
+
+/*
+ * Map crashkernel memory
+ */
+void crash_map_reserved_pages(void)
+{
+ crash_map_pages(1);
+}
+
+/*
+ * Unmap crashkernel memory
+ */
+void crash_unmap_reserved_pages(void)
+{
+ crash_map_pages(0);
+}
+
+/*
* Give back memory to hypervisor before new kdump is loaded
*/
static int machine_kexec_prepare_kdump(void)
--- a/arch/s390/kernel/setup.c
+++ b/arch/s390/kernel/setup.c
@@ -446,6 +446,7 @@ static void __init setup_resources(void)
res->flags = IORESOURCE_BUSY | IORESOURCE_MEM;
switch (memory_chunk[i].type) {
case CHUNK_READ_WRITE:
+ case CHUNK_CRASHK:
res->name = "System RAM";
break;
case CHUNK_READ_ONLY:
@@ -706,8 +707,8 @@ static void __init reserve_crashkernel(v
&crash_base);
if (rc || crash_size == 0)
return;
- crash_base = PAGE_ALIGN(crash_base);
- crash_size = PAGE_ALIGN(crash_size);
+ crash_base = ALIGN(crash_base, KEXEC_CRASH_MEM_ALIGN);
+ crash_size = ALIGN(crash_size, KEXEC_CRASH_MEM_ALIGN);
if (register_memory_notifier(&kdump_mem_nb))
return;
if (!crash_base)
@@ -727,7 +728,7 @@ static void __init reserve_crashkernel(v
crashk_res.start = crash_base;
crashk_res.end = crash_base + crash_size - 1;
insert_resource(&iomem_resource, &crashk_res);
- reserve_kdump_bootmem(crash_base, crash_size, CHUNK_READ_WRITE);
+ reserve_kdump_bootmem(crash_base, crash_size, CHUNK_CRASHK);
pr_info("Reserving %lluMB of memory at %lluMB "
"for crashkernel (System RAM: %luMB)\n",
crash_size >> 20, crash_base >> 20, memory_end >> 20);
@@ -802,7 +803,8 @@ setup_memory(void)
for (i = 0; i < MEMORY_CHUNKS && memory_chunk[i].size > 0; i++) {
unsigned long start_chunk, end_chunk, pfn;
- if (memory_chunk[i].type != CHUNK_READ_WRITE)
+ if (memory_chunk[i].type != CHUNK_READ_WRITE &&
+ memory_chunk[i].type != CHUNK_CRASHK)
continue;
start_chunk = PFN_DOWN(memory_chunk[i].addr);
end_chunk = start_chunk + PFN_DOWN(memory_chunk[i].size);
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[patch v2 0/2] kdump: Allow removal of page tables for crashkernel memory
Hello Vivek, Andrew, Martin Here the updated patch series for the removal of page tables for the crashkernel memory: [1] kdump: Add infrastructure for unmapping crashkernel memory [2] s390: Add architecture code for unmapping crashkernel memory The patches apply on top of the last kdump patch series that I sent. I would suggest that Martin sends the patches together with the other s390 kdump patches in the next merge window. Andrew is that ok for you? Michael ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[patch v2 1/2] kdump: Add infrastructure for unmapping crashkernel memory
From: Michael Holzheu
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. Two new
functions crash_map_reserved_pages() and crash_unmap_reserved_pages() are
added that can be implemented by architecture code. The
crash_map_reserved_pages() function is called before and
crash_unmap_reserved_pages() after the crashkernel segments are loaded. The
functions are also called in crash_shrink_memory() to create/remove 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
---
include/linux/kexec.h |6 ++
kernel/kexec.c| 21 +++--
2 files changed, 25 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,8 @@ 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_reserved_pages(void);
+void crash_unmap_reserved_pages(void);
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_reserved_pages();
}
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_unmap_reserved_pages();
}
/* Install the new kernel, and Uninstall the old */
image = xchg(dest_image, image);
@@ -1026,6 +1029,18 @@ out:
return result;
}
+/*
+ * Add and remove page tables for crashkernel memory
+ *
+ * Provide an empty default implementation here -- architecture
+ * code may override this
+ */
+void __weak crash_map_reserved_pages(void)
+{}
+
+void __weak crash_unmap_reserved_pages(void)
+{}
+
#ifdef CONFIG_COMPAT
asmlinkage long compat_sys_kexec_load(unsigned long entry,
unsigned long nr_segments,
@@ -1134,14 +1149,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_reserved_pages();
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_unmap_reserved_pages();
unlock:
mutex_unlock(&kexec_mutex);
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC][patch 1/2] kdump: Add infrastructure for unmapping crashkernel memory
On Mon, Sep 12, 2011 at 05:55:02PM +0200, Michael Holzheu wrote: > Hello Vivek, > > On Fri, 2011-09-09 at 14:23 -0400, Vivek Goyal wrote: > > On Thu, Sep 08, 2011 at 03:26:10PM +0200, Michael Holzheu wrote: > > > From: Michael Holzheu > > > > > > 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: > > > > I guess having separate functions for mapping and unmapping pages might > > look cleaner. Because we are not passing a page range, so specifying > > what pages we are talking about in function name might make it more > > clear. > > > > crash_map_reserved_pages() > > crash_unmap_reserved_pages(). > > Ok fine, no problem. > > > Secondly, what happens to the code which runs after crash (crash_kexec()). > > Current x86 code assumes that reserved region is mapped at the time of > > crash and does few things with control page there. > > For s390, purgatory code can run in real mode. No page tables are > required. > > > So this generic approach is not valid atleast for x86, because it does > > not tackle the scenario about how to map reserved range again once > > kernel crashes. It will only work if there is assumption that after > > a crash, we don't expect reserved range/pages to be mapped. > > All architectures that support unmapping of crashkernel memory have to > deal with this problem somehow. Either remap the crashkernel memory in > machine_kexec() again or be able to run in real mode. > > I adjusted that patch regarding your comment above. Will the following > patch be ok for you? I guess it is fine. Atleast conceptually it makes sense to unmap the reserved memory pages to avoid accidental corruption from some kernel code. It does not take care of some kind of DMA happening to this memory location though. I am not an memory management expert so not sure if this is best way to call unmap/map pages for some calls already exist which can do the job. Anyway, this change is not visible to user and changes can be done later also without impacting anything else so it is a low risk change that way. So yes, please repost the series (as you need to change second patch also to reflect new function names). I will ack the first patch. Thanks Vivek > --- > Subject: kdump: Add infrastructure for unmapping crashkernel memory > > From: Michael Holzheu > > 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. Two new > functions crash_map_reserved_pages() and crash_unmap_reserved_pages() are > added that can be implemented by architecture code. The > crash_map_reserved_pages() function is called before and > crash_unmap_reserved_pages() after the crashkernel segments are loaded. The > functions are also called in crash_shrink_memory() to create/remove 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 > --- > include/linux/kexec.h |6 ++ > kernel/kexec.c| 21 +++-- > 2 files changed, 25 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,8 @@ 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_reserved_pages(void); > +void crash_unmap_reserved_pages(void); > 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_reserved_pages(); > } > if (result) > goto out; > @@ -1015,6 +1016,8 @@ SYSCALL_DEFINE4(kexec_load, u
Re: makedumpfile: Add erased information in compressed kdump file and ELF formatted dumpfile
On 09/12/2011 11:54 PM, Dave Anderson wrote:
>
> Hi Mahesh,
>
> Now that this feature is in makedumpfile-1.4.0, I presume that you
> have crash utility "warning" patches underway?
Yup. I am working on it, will post the patches very soon.
>
> Also, can you confirm that compressed or kdumps with (or without)
> eraseinfo data can still be handled with no problem by the current
> version of the crash utility? I'm not talking about the ramifications
> of whatever kernel data may have been erased, but whether the changes to
> the dumpfile headers could cause a problem. I'm presuming that the
> compressed kdump eraseinfo data would be invisible to an older version
> of crash, and that ELF kdump eraseinfo would just show up as an (unused)
> ELF note -- but I just want to make sure.
Yes. The changes to dumpfile header and addition of eraseinfo data/ELF
note will not cause any problems with older crash version. With the
current version of crash the ELF kdump eraseinfo note would show up as
below:
Elf64_Nhdr:
n_namesz: 10 ("ERASEINFO")
n_descsz: 56
n_type: 0 (?)
206573617265 72616a5f64657263
697320656d616e2e 650a36353220657a
656e692065736172 736f746f72705f74
303120657a697320
Thanks,
-Mahesh.
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
