* Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled [not found] <mailman.65015.1477545113.1639.kexec@lists.infradead.org> @ 2016-10-27 13:25 ` Dave Anderson 0 siblings, 0 replies; 13+ messages in thread From: Dave Anderson @ 2016-10-27 13:25 UTC (permalink / raw) To: kexec ----- Original Message ----- > > I put the cped-vmcore/vmlinux here: > https://people.redhat.com/~ruyang/test/ > > Adding Dave Anderson for any comments about the vmcore correctness from > crash point of view.. > As it turns out, the vmcore.makedumpfile can be read just fine: $ crash vmlinux.kaslr vmcore.makedumpfile crash 7.1.7rc9 Copyright (C) 2002-2016 Red Hat, Inc. Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation Copyright (C) 1999-2006 Hewlett-Packard Co Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited Copyright (C) 2006, 2007 VA Linux Systems Japan K.K. Copyright (C) 2005, 2011 NEC Corporation Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc. Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc. This program is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Enter "help copying" to see the conditions. This program has absolutely no warranty. Enter "help warranty" for details. GNU gdb (GDB) 7.6 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu"... WARNING: kernel relocated [602MB]: patching 55325 gdb minimal_symbol values KERNEL: vmlinux.kaslr DUMPFILE: vmcore.makedumpfile [PARTIAL DUMP] CPUS: 1 DATE: Thu Oct 27 02:07:46 2016 UPTIME: 00:00:41 LOAD AVERAGE: 0.14, 0.04, 0.01 TASKS: 107 NODENAME: localhost.localdomain RELEASE: 4.9.0-rc2+ VERSION: #185 SMP Wed Oct 26 11:23:54 CST 2016 MACHINE: x86_64 (2294 Mhz) MEMORY: 1 GB PANIC: "sysrq: SysRq : Trigger a crash" PID: 1934 COMMAND: "bash" TASK: ffff9ca3bc155e00 [THREAD_INFO: ffff9ca3bc155e00] CPU: 0 STATE: TASK_RUNNING (SYSRQ) crash> bt PID: 1934 TASK: ffff9ca3bc155e00 CPU: 0 COMMAND: "bash" #0 [ffffb2df4033fa08] machine_kexec at ffffffffa6a34e09 #1 [ffffb2df4033fa68] __crash_kexec at ffffffffa6ab945a #2 [ffffb2df4033fb30] __crash_kexec at ffffffffa6ab9530 #3 [ffffb2df4033fb48] crash_kexec at ffffffffa6ab9576 #4 [ffffb2df4033fb68] oops_end at ffffffffa6a1529f #5 [ffffb2df4033fb90] no_context at ffffffffa6a3f67b #6 [ffffb2df4033fbf8] __bad_area_nosemaphore at ffffffffa6a3f8cc #7 [ffffb2df4033fc48] bad_area at ffffffffa6a3fa71 #8 [ffffb2df4033fc70] __do_page_fault at ffffffffa6a4004d #9 [ffffb2df4033fcd8] do_page_fault at ffffffffa6a40100 #10 [ffffb2df4033fd08] do_async_page_fault at ffffffffa6a3bbc5 #11 [ffffb2df4033fd20] async_page_fault at ffffffffa6f9f1e5 [exception RIP: sysrq_handle_crash+17] RIP: ffffffffa6d3a101 RSP: ffffb2df4033fdd8 RFLAGS: 00010282 RAX: 000000000000000f RBX: 0000000000000063 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff9ca3be60cc28 RDI: 0000000000000063 RBP: ffffb2df4033fdd8 R8: 0000000000000001 R9: 0000000000000006 R10: 0000000000000001 R11: 0000000000000172 R12: 0000000000000007 R13: 0000000000000000 R14: ffffffffa745b4a0 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #12 [ffffb2df4033fde0] __handle_sysrq at ffffffffa6d3a821 #13 [ffffb2df4033fe10] write_sysrq_trigger at ffffffffa6d3ac4a #14 [ffffb2df4033fe28] proc_reg_write at ffffffffa6bb73dd #15 [ffffb2df4033fe48] __vfs_write at ffffffffa6b55b02 #16 [ffffb2df4033fed0] vfs_write at ffffffffa6b56dbc #17 [ffffb2df4033ff08] sys_write at ffffffffa6b58060 #18 [ffffb2df4033ff50] entry_SYSCALL_64_fastpath at ffffffffa6f9dbbb RIP: 00007f0b401a9c20 RSP: 00007ffe38d75698 RFLAGS: 00000246 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f0b401a9c20 RDX: 0000000000000002 RSI: 00005577bf7de790 RDI: 0000000000000001 RBP: 0000000000000001 R8: 00007f0b40474740 R9: 00007f0b40ab7b40 R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe38d75c10 R14: 0000000000000000 R15: 0000000000000000 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b crash> But the ELF vmcore fails: $ crash vmlinux.kaslr vmcore crash 7.1.7rc9 Copyright (C) 2002-2016 Red Hat, Inc. Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation Copyright (C) 1999-2006 Hewlett-Packard Co Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited Copyright (C) 2006, 2007 VA Linux Systems Japan K.K. Copyright (C) 2005, 2011 NEC Corporation Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc. Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc. This program is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Enter "help copying" to see the conditions. This program has absolutely no warranty. Enter "help warranty" for details. GNU gdb (GDB) 7.6 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu"... WARNING: kernel relocated [602MB]: patching 55325 gdb minimal_symbol values WARNING: could not find MAGIC_START! WARNING: cannot read linux_banner string crash: vmlinux.kaslr and vmcore do not match! Usage: crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS] (dumpfile form) crash [OPTION]... [NAMELIST] (live system form) Enter "crash -h" for details. $ Since the data being read was bogus, the first thing I checked was whether the phys_base value was being calculated correctly. I manually applied the phys_base that was stored in the compressed dump header, and the ELF vmcore can be read: $ crash --machdep phys_base=ffffffffdf400000 vmlinux.kaslr vmcore crash 7.1.7rc9 Copyright (C) 2002-2016 Red Hat, Inc. Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation Copyright (C) 1999-2006 Hewlett-Packard Co Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited Copyright (C) 2006, 2007 VA Linux Systems Japan K.K. Copyright (C) 2005, 2011 NEC Corporation Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc. Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc. This program is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Enter "help copying" to see the conditions. This program has absolutely no warranty. Enter "help warranty" for details. NOTE: setting phys_base to: 0xffffffffdf400000 GNU gdb (GDB) 7.6 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu"... WARNING: kernel relocated [602MB]: patching 55325 gdb minimal_symbol values KERNEL: vmlinux.kaslr DUMPFILE: vmcore CPUS: 1 DATE: Thu Oct 27 02:07:46 2016 UPTIME: 00:00:41 LOAD AVERAGE: 0.14, 0.04, 0.01 TASKS: 107 NODENAME: localhost.localdomain RELEASE: 4.9.0-rc2+ VERSION: #185 SMP Wed Oct 26 11:23:54 CST 2016 MACHINE: x86_64 (2294 Mhz) MEMORY: 1 GB PANIC: "sysrq: SysRq : Trigger a crash" PID: 1934 COMMAND: "bash" TASK: ffff9ca3bc155e00 [THREAD_INFO: ffff9ca3bc155e00] CPU: 0 STATE: TASK_RUNNING (SYSRQ) crash> That being said, my recent 4.8 and 4.9 KASLR testing has been on live systems and compressed kdumps, so the old tried-and-true manner of calculating the phys_base from the ELF PT_LOAD segments apparently no longer works with KASLR. It would be so much more helpful if the VMCOREINFO data in the ELF header stored the actual phys_base value instead of its symbol value: crash> help -D ... SYMBOL(phys_base)=ffffffffa740b010 ... which is completely useless unless the phys_base value is known. Anyway, can you send me the makedumpfile code that calculates the phys_base value? Dave _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled @ 2016-10-24 16:48 Pratyush Anand 2016-10-25 9:17 ` Louis Bouchard 2016-10-27 2:37 ` Dave Young 0 siblings, 2 replies; 13+ messages in thread From: Pratyush Anand @ 2016-10-24 16:48 UTC (permalink / raw) To: ats-kumagai; +Cc: Pratyush Anand, dyoung, kexec, bhe Patch 1/4 fixes page_offset calculation, so that it is correctly calculated on KASLR enabled kernel as well. Patch 2/4 simplifies VA to PA translation. New code has been benchmarked against old code on a 4T system. Patch 3/4 and 4/4 is removal of (now) unnecessary code. I think, we should find a way to kill find_vememmap() as well, so that VMEMMAP_START can be removed. I have very limited idea about x86, so unable to do that as of now. Pratyush Anand (4): x86_64: Calculate page_offset from pt_load x86_64: translate all VA to PA using page table values x86_64: kill is_vmalloc_addr_x86_64() x86_64: kill some unused initialization arch/x86_64.c | 84 ++++++++++++++++++++-------------------------------------- makedumpfile.h | 9 +++---- 2 files changed, 32 insertions(+), 61 deletions(-) -- 2.7.4 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled 2016-10-24 16:48 Pratyush Anand @ 2016-10-25 9:17 ` Louis Bouchard 2016-10-25 9:20 ` Pratyush Anand 2016-10-27 2:37 ` Dave Young 1 sibling, 1 reply; 13+ messages in thread From: Louis Bouchard @ 2016-10-25 9:17 UTC (permalink / raw) To: Pratyush Anand, ats-kumagai; +Cc: kexec, dyoung, bhe Hello, Le 24/10/2016 à 18:48, Pratyush Anand a écrit : > Patch 1/4 fixes page_offset calculation, so that it is correctly calculated > on KASLR enabled kernel as well. > Patch 2/4 simplifies VA to PA translation. New code has been benchmarked > against old code on a 4T system. > Patch 3/4 and 4/4 is removal of (now) unnecessary code. > > I think, we should find a way to kill find_vememmap() as well, so that > VMEMMAP_START can be removed. I have very limited idea about x86, so unable > to do that as of now. > > Pratyush Anand (4): > x86_64: Calculate page_offset from pt_load > x86_64: translate all VA to PA using page table values > x86_64: kill is_vmalloc_addr_x86_64() > x86_64: kill some unused initialization > > arch/x86_64.c | 84 ++++++++++++++++++++-------------------------------------- > makedumpfile.h | 9 +++---- > 2 files changed, 32 insertions(+), 61 deletions(-) > Cross-posting but FYI, this patch fixes the issue reported in the following thread : makedumpfile issues many readpage_elf: Attempt to read non-existent page[1] It corresponds to the commit identified by my kernel bisection. I will wait until it is accepted in Kumagai-san's tree to include it in Debian/Ubuntu. Kind regards, ...Louis [1] https://www.mail-archive.com/kexec@lists.infradead.org/msg16434.html -- Louis Bouchard Software engineer, Cloud & Sustaining eng. Canonical Ltd Ubuntu developer Debian Maintainer GPG : 429D 7A3B DD05 B6F8 AF63 B9C4 8B3D 867C 823E 7A61 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled 2016-10-25 9:17 ` Louis Bouchard @ 2016-10-25 9:20 ` Pratyush Anand 0 siblings, 0 replies; 13+ messages in thread From: Pratyush Anand @ 2016-10-25 9:20 UTC (permalink / raw) To: Louis Bouchard Cc: Kexec Mailing List, Atsushi Kumagai, Dave Young, Baoquan He Hi Louis, On Tue, Oct 25, 2016 at 2:47 PM, Louis Bouchard <louis.bouchard@canonical.com> wrote: > Hello, > > Le 24/10/2016 à 18:48, Pratyush Anand a écrit : >> Patch 1/4 fixes page_offset calculation, so that it is correctly calculated >> on KASLR enabled kernel as well. >> Patch 2/4 simplifies VA to PA translation. New code has been benchmarked >> against old code on a 4T system. >> Patch 3/4 and 4/4 is removal of (now) unnecessary code. >> >> I think, we should find a way to kill find_vememmap() as well, so that >> VMEMMAP_START can be removed. I have very limited idea about x86, so unable >> to do that as of now. >> >> Pratyush Anand (4): >> x86_64: Calculate page_offset from pt_load >> x86_64: translate all VA to PA using page table values >> x86_64: kill is_vmalloc_addr_x86_64() >> x86_64: kill some unused initialization >> >> arch/x86_64.c | 84 ++++++++++++++++++++-------------------------------------- >> makedumpfile.h | 9 +++---- >> 2 files changed, 32 insertions(+), 61 deletions(-) >> > > Cross-posting but FYI, this patch fixes the issue reported in the following > thread : makedumpfile issues many readpage_elf: Attempt to read non-existent page[1] > > It corresponds to the commit identified by my kernel bisection. > > I will wait until it is accepted in Kumagai-san's tree to include it in > Debian/Ubuntu. Thanks a lot for your testing. ~Pratyush _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled 2016-10-24 16:48 Pratyush Anand 2016-10-25 9:17 ` Louis Bouchard @ 2016-10-27 2:37 ` Dave Young 2016-10-27 2:54 ` Dave Young ` (2 more replies) 1 sibling, 3 replies; 13+ messages in thread From: Dave Young @ 2016-10-27 2:37 UTC (permalink / raw) To: Pratyush Anand; +Cc: ats-kumagai, kexec, bhe Hi Pratyush, On 10/24/16 at 10:18pm, Pratyush Anand wrote: > Patch 1/4 fixes page_offset calculation, so that it is correctly calculated > on KASLR enabled kernel as well. > Patch 2/4 simplifies VA to PA translation. New code has been benchmarked > against old code on a 4T system. > Patch 3/4 and 4/4 is removal of (now) unnecessary code. > > I think, we should find a way to kill find_vememmap() as well, so that > VMEMMAP_START can be removed. I have very limited idea about x86, so unable > to do that as of now. > > Pratyush Anand (4): > x86_64: Calculate page_offset from pt_load > x86_64: translate all VA to PA using page table values > x86_64: kill is_vmalloc_addr_x86_64() > x86_64: kill some unused initialization > > arch/x86_64.c | 84 ++++++++++++++++++++-------------------------------------- > makedumpfile.h | 9 +++---- > 2 files changed, 32 insertions(+), 61 deletions(-) > According to our test, with these patches the dumped vmcore is correct which means simple crash test `bt` works. But the saved vmcore size is larger than before. I collected two --message-level 31 logs with/without your patches, the kernel kaslr was disabled during my test so that we can focus on the vmcore size issue, it looks like mem_map address was not collected correctly. [please ignore the patched log extra debug message I added] --- unpatched-makedumpfile.txt 2016-10-27 10:31:34.152962407 +0800 +++ patched-makedumpfile.txt 2016-10-27 10:28:44.213952179 +0800 @@ -1,4 +1,4 @@ -[127.0.0.1-2016-10-27-10:27:03]# /tmp/makedumpfile -l -d 31 --message-level 31 vmcore vmcore.m.1 +[127.0.0.1-2016-10-27-10:27:03]# /home/dyoung/git/makedumpfile/makedumpfile -l -d 31 --message-level 31 vmcore vmcore.m sadump: does not have partition header sadump: read dump device as unknown format sadump: unknown format @@ -36,70 +36,76 @@ Memory type : SPARSEMEM_EX +printing memmap ..... mem_map (0) - mem_map : ffffea0000000000 + mem_map : 0 pfn_start : 0 pfn_end : 8000 +printing memmap ..... mem_map (1) - mem_map : ffffea0000200000 + mem_map : 0 pfn_start : 8000 pfn_end : 10000 +printing memmap ..... mem_map (2) - mem_map : ffffea0000400000 + mem_map : 0 pfn_start : 10000 pfn_end : 18000 +printing memmap ..... mem_map (3) - mem_map : ffffea0000600000 + mem_map : 0 pfn_start : 18000 pfn_end : 20000 +printing memmap ..... mem_map (4) - mem_map : ffffea0000800000 + mem_map : 0 pfn_start : 20000 pfn_end : 28000 +printing memmap ..... mem_map (5) - mem_map : ffffea0000a00000 + mem_map : 0 pfn_start : 28000 pfn_end : 30000 +printing memmap ..... mem_map (6) - mem_map : ffffea0000c00000 + mem_map : 0 pfn_start : 30000 pfn_end : 38000 +printing memmap ..... mem_map (7) - mem_map : ffffea0000e00000 + mem_map : 0 pfn_start : 38000 pfn_end : 3ffda mmap() is available on the kernel. Checking for memory holes : [100.0 %] |STEP [Checking for memory holes ] : 0.000030 seconds -Excluding unnecessary pages : [100.0 %] \STEP [Excluding unnecessary pages] : 0.007547 seconds -Checking for memory holes : [100.0 %] -STEP [Checking for memory holes ] : 0.000016 seconds -Checking for memory holes : [100.0 %] /STEP [Checking for memory holes ] : 0.000009 seconds -Excluding unnecessary pages : [100.0 %] |STEP [Excluding unnecessary pages] : 0.006623 seconds -Copying data : [100.0 %] \STEP [Copying data ] : 0.184442 seconds -Copying data : [100.0 %] -STEP [Copying data ] : 0.000041 seconds +Excluding unnecessary pages : [100.0 %] \STEP [Excluding unnecessary pages] : 0.000007 seconds +Checking for memory holes : [100.0 %] -STEP [Checking for memory holes ] : 0.000014 seconds +Checking for memory holes : [100.0 %] /STEP [Checking for memory holes ] : 0.000008 seconds +Excluding unnecessary pages : [100.0 %] |STEP [Excluding unnecessary pages] : 0.000007 seconds +Copying data : [100.0 %] /STEP [Copying data ] : 1.421661 seconds +Copying data : [100.0 %] |STEP [Copying data ] : 0.000036 seconds Writing erase info... -offset_eraseinfo: dd5c4e, size_eraseinfo: 0 +offset_eraseinfo: 888c149, size_eraseinfo: 0 Original pages : 0x0000000000030c7d - Excluded pages : 0x000000000002cf58 - Pages filled with zero : 0x00000000000002be - Non-private cache pages : 0x0000000000006574 - Private cache pages : 0x0000000000000f27 - User process data pages : 0x0000000000003481 - Free pages : 0x000000000002237e + Excluded pages : 0x000000000001d534 + Pages filled with zero : 0x000000000001d534 + Non-private cache pages : 0x0000000000000000 + Private cache pages : 0x0000000000000000 + User process data pages : 0x0000000000000000 + Free pages : 0x0000000000000000 Hwpoison pages : 0x0000000000000000 - Remaining pages : 0x0000000000003d25 - (The number of pages is reduced to 7%.) + Remaining pages : 0x0000000000013749 + (The number of pages is reduced to 39%.) Memory Hole : 0x000000000000f35d -------------------------------------------------- Total pages : 0x000000000003ffda -Cache hit: 29946, miss: 47, hit rate: 99.8% +Cache hit: 196285, miss: 201, hit rate: 99.9% -The dumpfile is saved to vmcore.m.1. +The dumpfile is saved to vmcore.m. makedumpfile Completed. -[root@dhcp-128-65 127.0.0.1-2016-10-27-10:27:03]# ls -lth vmcore.m* --rw------- 1 root root 14M Oct 27 10:30 vmcore.m.1 --rw------- 1 root root 137M Oct 27 10:28 vmcore.m +[root@dhcp-128-65 127.0.0.1-2016-10-27-10:27:03]# _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled 2016-10-27 2:37 ` Dave Young @ 2016-10-27 2:54 ` Dave Young 2016-10-27 6:19 ` Dave Young 2016-10-27 3:25 ` Baoquan He 2016-10-27 5:11 ` Pratyush Anand 2 siblings, 1 reply; 13+ messages in thread From: Dave Young @ 2016-10-27 2:54 UTC (permalink / raw) To: Pratyush Anand; +Cc: anderson, ats-kumagai, kexec, bhe I put the cped-vmcore/vmlinux here: https://people.redhat.com/~ruyang/test/ Adding Dave Anderson for any comments about the vmcore correctness from crash point of view.. On 10/27/16 at 10:37am, Dave Young wrote: > Hi Pratyush, > > On 10/24/16 at 10:18pm, Pratyush Anand wrote: > > Patch 1/4 fixes page_offset calculation, so that it is correctly calculated > > on KASLR enabled kernel as well. > > Patch 2/4 simplifies VA to PA translation. New code has been benchmarked > > against old code on a 4T system. > > Patch 3/4 and 4/4 is removal of (now) unnecessary code. > > > > I think, we should find a way to kill find_vememmap() as well, so that > > VMEMMAP_START can be removed. I have very limited idea about x86, so unable > > to do that as of now. > > > > Pratyush Anand (4): > > x86_64: Calculate page_offset from pt_load > > x86_64: translate all VA to PA using page table values > > x86_64: kill is_vmalloc_addr_x86_64() > > x86_64: kill some unused initialization > > > > arch/x86_64.c | 84 ++++++++++++++++++++-------------------------------------- > > makedumpfile.h | 9 +++---- > > 2 files changed, 32 insertions(+), 61 deletions(-) > > > > According to our test, with these patches the dumped vmcore is correct > which means simple crash test `bt` works. But the saved vmcore size is > larger than before. > > I collected two --message-level 31 logs with/without your patches, the > kernel kaslr was disabled during my test so that we can focus on the > vmcore size issue, it looks like mem_map address was not collected > correctly. > > [please ignore the patched log extra debug message I added] > > --- unpatched-makedumpfile.txt 2016-10-27 10:31:34.152962407 +0800 > +++ patched-makedumpfile.txt 2016-10-27 10:28:44.213952179 +0800 > @@ -1,4 +1,4 @@ > -[127.0.0.1-2016-10-27-10:27:03]# /tmp/makedumpfile -l -d 31 --message-level 31 vmcore vmcore.m.1 > +[127.0.0.1-2016-10-27-10:27:03]# /home/dyoung/git/makedumpfile/makedumpfile -l -d 31 --message-level 31 vmcore vmcore.m > sadump: does not have partition header > sadump: read dump device as unknown format > sadump: unknown format > @@ -36,70 +36,76 @@ > > Memory type : SPARSEMEM_EX > > +printing memmap ..... > mem_map (0) > - mem_map : ffffea0000000000 > + mem_map : 0 > pfn_start : 0 > pfn_end : 8000 > +printing memmap ..... > mem_map (1) > - mem_map : ffffea0000200000 > + mem_map : 0 > pfn_start : 8000 > pfn_end : 10000 > +printing memmap ..... > mem_map (2) > - mem_map : ffffea0000400000 > + mem_map : 0 > pfn_start : 10000 > pfn_end : 18000 > +printing memmap ..... > mem_map (3) > - mem_map : ffffea0000600000 > + mem_map : 0 > pfn_start : 18000 > pfn_end : 20000 > +printing memmap ..... > mem_map (4) > - mem_map : ffffea0000800000 > + mem_map : 0 > pfn_start : 20000 > pfn_end : 28000 > +printing memmap ..... > mem_map (5) > - mem_map : ffffea0000a00000 > + mem_map : 0 > pfn_start : 28000 > pfn_end : 30000 > +printing memmap ..... > mem_map (6) > - mem_map : ffffea0000c00000 > + mem_map : 0 > pfn_start : 30000 > pfn_end : 38000 > +printing memmap ..... > mem_map (7) > - mem_map : ffffea0000e00000 > + mem_map : 0 > pfn_start : 38000 > pfn_end : 3ffda > mmap() is available on the kernel. > Checking for memory holes : [100.0 %] |STEP [Checking for memory holes ] : 0.000030 seconds > -Excluding unnecessary pages : [100.0 %] \STEP [Excluding unnecessary pages] : 0.007547 seconds > -Checking for memory holes : [100.0 %] -STEP [Checking for memory holes ] : 0.000016 seconds > -Checking for memory holes : [100.0 %] /STEP [Checking for memory holes ] : 0.000009 seconds > -Excluding unnecessary pages : [100.0 %] |STEP [Excluding unnecessary pages] : 0.006623 seconds > -Copying data : [100.0 %] \STEP [Copying data ] : 0.184442 seconds > -Copying data : [100.0 %] -STEP [Copying data ] : 0.000041 seconds > +Excluding unnecessary pages : [100.0 %] \STEP [Excluding unnecessary pages] : 0.000007 seconds > +Checking for memory holes : [100.0 %] -STEP [Checking for memory holes ] : 0.000014 seconds > +Checking for memory holes : [100.0 %] /STEP [Checking for memory holes ] : 0.000008 seconds > +Excluding unnecessary pages : [100.0 %] |STEP [Excluding unnecessary pages] : 0.000007 seconds > +Copying data : [100.0 %] /STEP [Copying data ] : 1.421661 seconds > +Copying data : [100.0 %] |STEP [Copying data ] : 0.000036 seconds > > Writing erase info... > -offset_eraseinfo: dd5c4e, size_eraseinfo: 0 > +offset_eraseinfo: 888c149, size_eraseinfo: 0 > > Original pages : 0x0000000000030c7d > - Excluded pages : 0x000000000002cf58 > - Pages filled with zero : 0x00000000000002be > - Non-private cache pages : 0x0000000000006574 > - Private cache pages : 0x0000000000000f27 > - User process data pages : 0x0000000000003481 > - Free pages : 0x000000000002237e > + Excluded pages : 0x000000000001d534 > + Pages filled with zero : 0x000000000001d534 > + Non-private cache pages : 0x0000000000000000 > + Private cache pages : 0x0000000000000000 > + User process data pages : 0x0000000000000000 > + Free pages : 0x0000000000000000 > Hwpoison pages : 0x0000000000000000 > - Remaining pages : 0x0000000000003d25 > - (The number of pages is reduced to 7%.) > + Remaining pages : 0x0000000000013749 > + (The number of pages is reduced to 39%.) > Memory Hole : 0x000000000000f35d > -------------------------------------------------- > Total pages : 0x000000000003ffda > > -Cache hit: 29946, miss: 47, hit rate: 99.8% > +Cache hit: 196285, miss: 201, hit rate: 99.9% > > > -The dumpfile is saved to vmcore.m.1. > +The dumpfile is saved to vmcore.m. > > makedumpfile Completed. > -[root@dhcp-128-65 127.0.0.1-2016-10-27-10:27:03]# ls -lth vmcore.m* > --rw------- 1 root root 14M Oct 27 10:30 vmcore.m.1 > --rw------- 1 root root 137M Oct 27 10:28 vmcore.m > +[root@dhcp-128-65 127.0.0.1-2016-10-27-10:27:03]# > > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled 2016-10-27 2:54 ` Dave Young @ 2016-10-27 6:19 ` Dave Young [not found] ` <926225735.8567580.1477574985798.JavaMail.zimbra@redhat.com> 0 siblings, 1 reply; 13+ messages in thread From: Dave Young @ 2016-10-27 6:19 UTC (permalink / raw) To: Pratyush Anand; +Cc: anderson, ats-kumagai, kexec, bhe On 10/27/16 at 10:54am, Dave Young wrote: > I put the cped-vmcore/vmlinux here: > https://people.redhat.com/~ruyang/test/ > > Adding Dave Anderson for any comments about the vmcore correctness from > crash point of view.. > Since the reason has been found, the page_offset was not correct, I tested with a changed version of patch 1, it works. Please ignore the test vmcore, I deleted them. Here is a new tarball which could be used by Dave to verify the kaslr, I enabled kaslr, also saved vmlinux/cped vmcore/makedumpfile saved vmcore in a tarball below. http://people.redhat.com/~ruyang/test/vmcore-test.tar.gz Thanks Dave _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <926225735.8567580.1477574985798.JavaMail.zimbra@redhat.com>]
* Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled [not found] ` <926225735.8567580.1477574985798.JavaMail.zimbra@redhat.com> @ 2016-10-27 15:25 ` Dave Anderson 2016-10-27 15:41 ` Dave Anderson 2016-10-27 15:59 ` Pratyush Anand 0 siblings, 2 replies; 13+ messages in thread From: Dave Anderson @ 2016-10-27 15:25 UTC (permalink / raw) To: Dave Young, kexec; +Cc: Pratyush Anand, ats-kumagai, bhe ----- Original Message ----- > > That being said, my recent 4.8 and 4.9 KASLR testing has been on live > systems and compressed kdumps, so the old tried-and-true manner of > calculating the phys_base from the ELF PT_LOAD segments apparently > no longer works with KASLR. > > It would be so much more helpful if the VMCOREINFO data in the ELF > header stored the actual phys_base value instead of its symbol value: > > crash> help -D > ... > SYMBOL(phys_base)=ffffffffa740b010 > ... > > which is completely useless unless the phys_base value is known. > > Anyway, can you send me the makedumpfile code that calculates the > phys_base value? > > Dave As it turns out, the problem with the crash utility is that it has to calculate phys_base well before it even knows the kernel has been relocated by KASLR. So when it sees the __START_KERNEL_map PT_LOAD segment, it mistakes it for the kernel modules' virtual address region and skips it. The kernel has this: #if defined(CONFIG_RANDOMIZE_BASE) #define KERNEL_IMAGE_SIZE (1024 * 1024 * 1024) #else #define KERNEL_IMAGE_SIZE (512 * 1024 * 1024) #endif and then this: #define MODULES_VADDR (__START_KERNEL_map + KERNEL_IMAGE_SIZE) So with KASLR, MODULES_VADDR gets pushed up from the traditional ffffffffa0000000 up to ffffffffc0000000. So I'm curious as to what you use in makedumpfile to determine whether CONFIG_RANDOMIZE_BASE has been configured? Thanks, Dave _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled 2016-10-27 15:25 ` Dave Anderson @ 2016-10-27 15:41 ` Dave Anderson 2016-10-28 2:04 ` Dave Young 2016-10-27 15:59 ` Pratyush Anand 1 sibling, 1 reply; 13+ messages in thread From: Dave Anderson @ 2016-10-27 15:41 UTC (permalink / raw) To: Dave Young, kexec; +Cc: Pratyush Anand, ats-kumagai, bhe ----- Original Message ----- > > > ----- Original Message ----- > > > > > That being said, my recent 4.8 and 4.9 KASLR testing has been on live > > systems and compressed kdumps, so the old tried-and-true manner of > > calculating the phys_base from the ELF PT_LOAD segments apparently > > no longer works with KASLR. > > > > It would be so much more helpful if the VMCOREINFO data in the ELF > > header stored the actual phys_base value instead of its symbol value: > > > > crash> help -D > > ... > > SYMBOL(phys_base)=ffffffffa740b010 > > ... > > > > which is completely useless unless the phys_base value is known. > > > > Anyway, can you send me the makedumpfile code that calculates the > > phys_base value? > > > > Dave > > As it turns out, the problem with the crash utility is that it has to > calculate phys_base well before it even knows the kernel has been relocated > by KASLR. So when it sees the __START_KERNEL_map PT_LOAD segment, it > mistakes > it for the kernel modules' virtual address region and skips it. > > The kernel has this: > > #if defined(CONFIG_RANDOMIZE_BASE) > #define KERNEL_IMAGE_SIZE (1024 * 1024 * 1024) > #else > #define KERNEL_IMAGE_SIZE (512 * 1024 * 1024) > #endif > > and then this: > > #define MODULES_VADDR (__START_KERNEL_map + KERNEL_IMAGE_SIZE) > > So with KASLR, MODULES_VADDR gets pushed up from the traditional ffffffffa0000000 > up to ffffffffc0000000. > > So I'm curious as to what you use in makedumpfile to determine whether > CONFIG_RANDOMIZE_BASE has been configured? > > Thanks, > Dave Hey, sorry, I didn't notice that this was added upstream: commit 1303a27c9c32020a3b6ac89be270d2ab1f28be24 Author: Baoquan He <bhe@redhat.com> Date: Wed Sep 9 15:39:03 2015 -0700 kexec: export KERNEL_IMAGE_SIZE to vmcoreinfo With that in place, it will be an easy fix for the crash utility. Thanks, Dave _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled 2016-10-27 15:41 ` Dave Anderson @ 2016-10-28 2:04 ` Dave Young 0 siblings, 0 replies; 13+ messages in thread From: Dave Young @ 2016-10-28 2:04 UTC (permalink / raw) To: Dave Anderson; +Cc: Pratyush Anand, ats-kumagai, kexec, bhe On 10/27/16 at 11:41am, Dave Anderson wrote: > > > ----- Original Message ----- > > > > > > ----- Original Message ----- > > > > > > > > That being said, my recent 4.8 and 4.9 KASLR testing has been on live > > > systems and compressed kdumps, so the old tried-and-true manner of > > > calculating the phys_base from the ELF PT_LOAD segments apparently > > > no longer works with KASLR. > > > > > > It would be so much more helpful if the VMCOREINFO data in the ELF > > > header stored the actual phys_base value instead of its symbol value: > > > > > > crash> help -D > > > ... > > > SYMBOL(phys_base)=ffffffffa740b010 > > > ... > > > > > > which is completely useless unless the phys_base value is known. > > > > > > Anyway, can you send me the makedumpfile code that calculates the > > > phys_base value? > > > > > > Dave > > > > As it turns out, the problem with the crash utility is that it has to > > calculate phys_base well before it even knows the kernel has been relocated > > by KASLR. So when it sees the __START_KERNEL_map PT_LOAD segment, it > > mistakes > > it for the kernel modules' virtual address region and skips it. > > > > The kernel has this: > > > > #if defined(CONFIG_RANDOMIZE_BASE) > > #define KERNEL_IMAGE_SIZE (1024 * 1024 * 1024) > > #else > > #define KERNEL_IMAGE_SIZE (512 * 1024 * 1024) > > #endif > > > > and then this: > > > > #define MODULES_VADDR (__START_KERNEL_map + KERNEL_IMAGE_SIZE) > > > > So with KASLR, MODULES_VADDR gets pushed up from the traditional ffffffffa0000000 > > up to ffffffffc0000000. > > > > So I'm curious as to what you use in makedumpfile to determine whether > > CONFIG_RANDOMIZE_BASE has been configured? > > > > Thanks, > > Dave > > Hey, sorry, I didn't notice that this was added upstream: > > commit 1303a27c9c32020a3b6ac89be270d2ab1f28be24 > Author: Baoquan He <bhe@redhat.com> > Date: Wed Sep 9 15:39:03 2015 -0700 > > kexec: export KERNEL_IMAGE_SIZE to vmcoreinfo > > With that in place, it will be an easy fix for the crash utility. Dave, I confirmed your fix in crash git tree works, it also works for the elf format vmcore, /proc/vmcore and makedumpfile -E created vmcore. Thanks for the quick fix.. > > Thanks, > Dave > > > > > > > > > > > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled 2016-10-27 15:25 ` Dave Anderson 2016-10-27 15:41 ` Dave Anderson @ 2016-10-27 15:59 ` Pratyush Anand 1 sibling, 0 replies; 13+ messages in thread From: Pratyush Anand @ 2016-10-27 15:59 UTC (permalink / raw) To: Dave Anderson, Dave Young, kexec; +Cc: ats-kumagai, bhe On Thursday 27 October 2016 08:55 PM, Dave Anderson wrote: > As it turns out, the problem with the crash utility is that it has to > calculate phys_base well before it even knows the kernel has been relocated > by KASLR. So when it sees the __START_KERNEL_map PT_LOAD segment, it mistakes > it for the kernel modules' virtual address region and skips it. > > The kernel has this: > > #if defined(CONFIG_RANDOMIZE_BASE) > #define KERNEL_IMAGE_SIZE (1024 * 1024 * 1024) > #else > #define KERNEL_IMAGE_SIZE (512 * 1024 * 1024) > #endif > > and then this: > > #define MODULES_VADDR (__START_KERNEL_map + KERNEL_IMAGE_SIZE) > > So with KASLR, MODULES_VADDR gets pushed up from the traditional ffffffffa0000000 > up to ffffffffc0000000. > > So I'm curious as to what you use in makedumpfile to determine whether > CONFIG_RANDOMIZE_BASE has been configured? So far we are trying to avoid to know that in makedumpfile. makedumpfile needed to know MODULES_VADDR, VMALLOC_START etc only to know that whether a VA to PA translation can be done using direct mapping or to be done by reading corresponding page table entry. Now, we do VA to PA for all VAs using page table entry only. https://github.com/pratyushanand/makedumpfile/blob/x86_devel/arch/x86_64.c#L186 ~Pratyush _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled 2016-10-27 2:37 ` Dave Young 2016-10-27 2:54 ` Dave Young @ 2016-10-27 3:25 ` Baoquan He 2016-10-27 5:11 ` Pratyush Anand 2 siblings, 0 replies; 13+ messages in thread From: Baoquan He @ 2016-10-27 3:25 UTC (permalink / raw) To: Dave Young; +Cc: Pratyush Anand, ats-kumagai, kexec On 10/27/16 at 10:37am, Dave Young wrote: > Hi Pratyush, > > On 10/24/16 at 10:18pm, Pratyush Anand wrote: > > Patch 1/4 fixes page_offset calculation, so that it is correctly calculated > > on KASLR enabled kernel as well. > > Patch 2/4 simplifies VA to PA translation. New code has been benchmarked > > against old code on a 4T system. > > Patch 3/4 and 4/4 is removal of (now) unnecessary code. > > > > I think, we should find a way to kill find_vememmap() as well, so that > > VMEMMAP_START can be removed. I have very limited idea about x86, so unable > > to do that as of now. > > > > Pratyush Anand (4): > > x86_64: Calculate page_offset from pt_load > > x86_64: translate all VA to PA using page table values > > x86_64: kill is_vmalloc_addr_x86_64() > > x86_64: kill some unused initialization > > > > arch/x86_64.c | 84 ++++++++++++++++++++-------------------------------------- > > makedumpfile.h | 9 +++---- > > 2 files changed, 32 insertions(+), 61 deletions(-) > > > > According to our test, with these patches the dumped vmcore is correct > which means simple crash test `bt` works. But the saved vmcore size is > larger than before. > > I collected two --message-level 31 logs with/without your patches, the > kernel kaslr was disabled during my test so that we can focus on the > vmcore size issue, it looks like mem_map address was not collected > correctly. From printing log, this is not correct. Without memmap, filtering can't be done correctly. > > [please ignore the patched log extra debug message I added] > > --- unpatched-makedumpfile.txt 2016-10-27 10:31:34.152962407 +0800 > +++ patched-makedumpfile.txt 2016-10-27 10:28:44.213952179 +0800 > @@ -1,4 +1,4 @@ > -[127.0.0.1-2016-10-27-10:27:03]# /tmp/makedumpfile -l -d 31 --message-level 31 vmcore vmcore.m.1 > +[127.0.0.1-2016-10-27-10:27:03]# /home/dyoung/git/makedumpfile/makedumpfile -l -d 31 --message-level 31 vmcore vmcore.m > sadump: does not have partition header > sadump: read dump device as unknown format > sadump: unknown format > @@ -36,70 +36,76 @@ > > Memory type : SPARSEMEM_EX > > +printing memmap ..... > mem_map (0) > - mem_map : ffffea0000000000 > + mem_map : 0 > pfn_start : 0 > pfn_end : 8000 > +printing memmap ..... > mem_map (1) > - mem_map : ffffea0000200000 > + mem_map : 0 > pfn_start : 8000 > pfn_end : 10000 > +printing memmap ..... > mem_map (2) > - mem_map : ffffea0000400000 > + mem_map : 0 > pfn_start : 10000 > pfn_end : 18000 > +printing memmap ..... > mem_map (3) > - mem_map : ffffea0000600000 > + mem_map : 0 > pfn_start : 18000 > pfn_end : 20000 > +printing memmap ..... > mem_map (4) > - mem_map : ffffea0000800000 > + mem_map : 0 > pfn_start : 20000 > pfn_end : 28000 > +printing memmap ..... > mem_map (5) > - mem_map : ffffea0000a00000 > + mem_map : 0 > pfn_start : 28000 > pfn_end : 30000 > +printing memmap ..... > mem_map (6) > - mem_map : ffffea0000c00000 > + mem_map : 0 > pfn_start : 30000 > pfn_end : 38000 > +printing memmap ..... > mem_map (7) > - mem_map : ffffea0000e00000 > + mem_map : 0 > pfn_start : 38000 > pfn_end : 3ffda > mmap() is available on the kernel. > Checking for memory holes : [100.0 %] |STEP [Checking for memory holes ] : 0.000030 seconds > -Excluding unnecessary pages : [100.0 %] \STEP [Excluding unnecessary pages] : 0.007547 seconds > -Checking for memory holes : [100.0 %] -STEP [Checking for memory holes ] : 0.000016 seconds > -Checking for memory holes : [100.0 %] /STEP [Checking for memory holes ] : 0.000009 seconds > -Excluding unnecessary pages : [100.0 %] |STEP [Excluding unnecessary pages] : 0.006623 seconds > -Copying data : [100.0 %] \STEP [Copying data ] : 0.184442 seconds > -Copying data : [100.0 %] -STEP [Copying data ] : 0.000041 seconds > +Excluding unnecessary pages : [100.0 %] \STEP [Excluding unnecessary pages] : 0.000007 seconds > +Checking for memory holes : [100.0 %] -STEP [Checking for memory holes ] : 0.000014 seconds > +Checking for memory holes : [100.0 %] /STEP [Checking for memory holes ] : 0.000008 seconds > +Excluding unnecessary pages : [100.0 %] |STEP [Excluding unnecessary pages] : 0.000007 seconds > +Copying data : [100.0 %] /STEP [Copying data ] : 1.421661 seconds > +Copying data : [100.0 %] |STEP [Copying data ] : 0.000036 seconds > > Writing erase info... > -offset_eraseinfo: dd5c4e, size_eraseinfo: 0 > +offset_eraseinfo: 888c149, size_eraseinfo: 0 > > Original pages : 0x0000000000030c7d > - Excluded pages : 0x000000000002cf58 > - Pages filled with zero : 0x00000000000002be > - Non-private cache pages : 0x0000000000006574 > - Private cache pages : 0x0000000000000f27 > - User process data pages : 0x0000000000003481 > - Free pages : 0x000000000002237e > + Excluded pages : 0x000000000001d534 > + Pages filled with zero : 0x000000000001d534 > + Non-private cache pages : 0x0000000000000000 > + Private cache pages : 0x0000000000000000 > + User process data pages : 0x0000000000000000 > + Free pages : 0x0000000000000000 > Hwpoison pages : 0x0000000000000000 > - Remaining pages : 0x0000000000003d25 > - (The number of pages is reduced to 7%.) > + Remaining pages : 0x0000000000013749 > + (The number of pages is reduced to 39%.) > Memory Hole : 0x000000000000f35d > -------------------------------------------------- > Total pages : 0x000000000003ffda > > -Cache hit: 29946, miss: 47, hit rate: 99.8% > +Cache hit: 196285, miss: 201, hit rate: 99.9% > > > -The dumpfile is saved to vmcore.m.1. > +The dumpfile is saved to vmcore.m. > > makedumpfile Completed. > -[root@dhcp-128-65 127.0.0.1-2016-10-27-10:27:03]# ls -lth vmcore.m* > --rw------- 1 root root 14M Oct 27 10:30 vmcore.m.1 > --rw------- 1 root root 137M Oct 27 10:28 vmcore.m > +[root@dhcp-128-65 127.0.0.1-2016-10-27-10:27:03]# > > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled 2016-10-27 2:37 ` Dave Young 2016-10-27 2:54 ` Dave Young 2016-10-27 3:25 ` Baoquan He @ 2016-10-27 5:11 ` Pratyush Anand 2 siblings, 0 replies; 13+ messages in thread From: Pratyush Anand @ 2016-10-27 5:11 UTC (permalink / raw) To: Dave Young; +Cc: ats-kumagai, kexec, bhe On Thursday 27 October 2016 08:07 AM, Dave Young wrote: > According to our test, with these patches the dumped vmcore is correct > which means simple crash test `bt` works. But the saved vmcore size is > larger than before. > > I collected two --message-level 31 logs with/without your patches, the > kernel kaslr was disabled during my test so that we can focus on the > vmcore size issue, it looks like mem_map address was not collected > correctly. > > [please ignore the patched log extra debug message I added] Hummm..thanks for pointing it out. Seems patch 1/4 is wrong. with this patch page_offset = ffffffff80000000 while with original code page_offset = ffff880000000000 Trying to see where it is wrong ~Pratyush _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2016-10-28 2:04 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <mailman.65015.1477545113.1639.kexec@lists.infradead.org>
2016-10-27 13:25 ` [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled Dave Anderson
2016-10-24 16:48 Pratyush Anand
2016-10-25 9:17 ` Louis Bouchard
2016-10-25 9:20 ` Pratyush Anand
2016-10-27 2:37 ` Dave Young
2016-10-27 2:54 ` Dave Young
2016-10-27 6:19 ` Dave Young
[not found] ` <926225735.8567580.1477574985798.JavaMail.zimbra@redhat.com>
2016-10-27 15:25 ` Dave Anderson
2016-10-27 15:41 ` Dave Anderson
2016-10-28 2:04 ` Dave Young
2016-10-27 15:59 ` Pratyush Anand
2016-10-27 3:25 ` Baoquan He
2016-10-27 5:11 ` Pratyush Anand
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.