kexec November 2013

kexec@lists.fedoraproject.org

7 participants
6 discussions

[PATCH 0/2] two backports for makedumpfile
by WANG Chao 27 Nov '13

27 Nov '13

Hi, there's two backports I'd like to pull in. The first one is addressing broken --dump-dmesg issue towards 3.11 kernel and later. The second one fixes filter issues on powerpc when CONFIG_SPARSEMEM_VMEMMAP is set. Actually, I only plan to pull in the 2nd patch. But since 2nd patch can not be applied directly without the 1st one and I want to keep all the backport as clean as possible. So I decide to pull in the both patches. PS. I don't think 1st patch would cause any regression Please review these and let me know if you have any concern. WANG Chao (2): makedumpfile: Understand >= v3.11-rc4 dmesg. makedumpfile, ppc: Support to filter dump for kernels that use CONFIG_SPARSEMEM_VMEMMAP. ...pport-to-filter-dump-for-kernels-that-use.patch | 429 +++++++++++++++++++++ ...4-makedumpfile-Understand-v3.11-rc4-dmesg.patch | 197 ++++++++++ kexec-tools.spec | 4 + 3 files changed, 630 insertions(+) create mode 100644 kexec-tools-2.0.4-makedumpfile-Support-to-filter-dump-for-kernels-that-use.patch create mode 100644 kexec-tools-2.0.4-makedumpfile-Understand-v3.11-rc4-dmesg.patch -- 1.8.3.1

3 4

[PATCH] kdumpctl: Avoid leaking fd to subshell
by WANG Chao 26 Nov '13

26 Nov '13

We only allow one instance of kdump service running at each time by flock /var/lock/kdump which is opened as fd 9 in kdumpctl script. However a leaking fd issue has been discovered by SELinux: When executing a specific shell command (not the shell built-in but provided by other packages, in this case - restorecon) in kdumpctl, current shell will fork a new subshell for executing and the subshell will inherit open fd 9 from parent shell. And SELinux detects that subshell is holding the open fd and consider fd 9 is leaked. To avoid this kind of leaking, the most easy way seems to be breaking our kdumpctl code out into two parts: - A top level parent shell, which is only used to deal with the lock and invoking the subshell below. - A 2nd tier level subshell, which is closing the inherited open fd at very first and doing the rest of the kdumpctl job. So that it isn't leaking fd to its subshell when executing like restorecon, etc. To be easy to understand, the callgraph is roughly like below: [..] --> open(9) --> flock(9) --> fork --> close(9) <-- we close 9 right here --> main() <-- we're now doing the real job --> [..] --> fork() --> restorecon <-- we don't leak fd 9 to child process --> [..] --> [..] As shown above, a wrapper main() is added as the 2nd tier level shell in this kind of call model. So we can completely avoid leaking fd to subshell. Signed-off-by: WANG Chao <chaowang(a)redhat.com> --- kdumpctl | 91 ++++++++++++++++++++++++++++++++++------------------------------ 1 file changed, 49 insertions(+), 42 deletions(-) diff --git a/kdumpctl b/kdumpctl index 358ef05..46ae633 100755 --- a/kdumpctl +++ b/kdumpctl @@ -543,52 +543,59 @@ if [ ! -f "$KDUMP_CONFIG_FILE" ]; then exit 1 fi -# Other kdumpctl instances will block in queue, until this one exits -single_instance_lock - -case "$1" in - start) - if [ -s /proc/vmcore ]; then - save_core - reboot - else - start - fi - ;; - stop) - stop - ;; - status) - EXIT_CODE=0 - status - case "$?" in - 0) - echo "Kdump is operational" +main () +{ + case "$1" in + start) + if [ -s /proc/vmcore ]; then + save_core + reboot + else + start + fi + ;; + stop) + stop + ;; + status) EXIT_CODE=0 + status + case "$?" in + 0) + echo "Kdump is operational" + EXIT_CODE=0 + ;; + 1) + echo "Kdump is not operational" + EXIT_CODE=3 + ;; + 2) + echo "Kdump is unsupported on this kernel" + EXIT_CODE=3 + ;; + esac + exit $EXIT_CODE ;; - 1) - echo "Kdump is not operational" - EXIT_CODE=3 + restart) + stop + start + ;; + condrestart) ;; - 2) - echo "Kdump is unsupported on this kernel" - EXIT_CODE=3 + propagate) + propagate_ssh_key ;; + *) + echo $"Usage: $0 {start|stop|status|restart|propagate}" + exit 1 esac - exit $EXIT_CODE - ;; - restart) - stop - start - ;; - condrestart) - ;; - propagate) - propagate_ssh_key - ;; - *) - echo $"Usage: $0 {start|stop|status|restart|propagate}" - exit 1 -esac +} + +# Other kdumpctl instances will block in queue, until this one exits +single_instance_lock + +# To avoid fd 9 leaking, we invoke a subshell, close fd 9 and call main. +# So that fd isn't leaking when main is invoking a subshell. +(exec 9<&-; main $1) exit $? -- 1.8.3.1

2 1

crash on F20 beta says log_buf data structure has changed
by Vivek Goyal 20 Nov '13

20 Nov '13

Hi Dave, I captured a crash of F20 beta system and opened vmcore. crash gives me warning that log_buf has changed and "log" command does not output anything. I thought you fixed it. Is it just a problem of pushing crash update to F20? Thanks Vivek # crash /usr/lib/debug/lib/modules/3.11.8-300.fc20.x86_64/vmlinux vmcore crash 7.0.1-2.fc20 Copyright (C) 2002-2013 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"... KERNEL: /usr/lib/debug/lib/modules/3.11.8-300.fc20.x86_64/vmlinux DUMPFILE: vmcore [PARTIAL DUMP] CPUS: 4 DATE: Tue Nov 19 16:33:43 2013 UPTIME: 00:03:24 LOAD AVERAGE: 0.18, 0.37, 0.18 TASKS: 172 NODENAME: <Edited> RELEASE: 3.11.8-300.fc20.x86_64 VERSION: #1 SMP Wed Nov 13 16:34:27 UTC 2013 MACHINE: x86_64 (2333 Mhz) MEMORY: 4 GB PANIC: WARNING: log buf data structure(s) have changed "" PID: 10584 COMMAND: "bash" TASK: ffff8801371d96e0 [THREAD_INFO: ffff880138dd8000] CPU: 3 STATE: TASK_RUNNING (PANIC) crash> log log: WARNING: log buf data structure(s) have changed

2 4

[PATCH] Add rd.memdebug in kdump module
by Arthur Zou 20 Nov '13

20 Nov '13

Description: Currently we only added memdebug code before different dracut hooks ie. pre-udev pre-pivot etc. Add memdebug in kdump.sh before capturing vmcore is also good for debugging. solution: Add make_trace_mem before saving vmcore. --- dracut-kdump.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dracut-kdump.sh b/dracut-kdump.sh index f38891d..d157cd1 100755 --- a/dracut-kdump.sh +++ b/dracut-kdump.sh @@ -312,7 +312,7 @@ if [ $? -ne 0 ]; then echo "kdump: kdump_pre script exited with non-zero status!" do_final_action fi - +make_trace_mem "kdump saving vmcore" '1:shortmem' '2+:mem' '3+:slab' do_dump DUMP_RETVAL=$? -- 1.8.3.1

3 3

[PATCH] makedumpfile: disable mmap
by Dave Young 20 Nov '13

20 Nov '13

There's a kernel bug for mapping mem ranges which end with an address not aligned to page boundry. It's still not resolved in upstream, so let's disable mmap read for now as a workaround. Once upstream got a right fix we can revert this patch. Signed-off-by: Dave Young <dyoung(a)redhat.com> --- kexec-tools-2.0.4-makedumpfile-disable-mmap.patch | 36 +++++++++++++++++++++++ kexec-tools.spec | 2 ++ 2 files changed, 38 insertions(+) create mode 100644 kexec-tools-2.0.4-makedumpfile-disable-mmap.patch diff --git a/kexec-tools-2.0.4-makedumpfile-disable-mmap.patch b/kexec-tools-2.0.4-makedumpfile-disable-mmap.patch new file mode 100644 index 0000000..125b62f --- /dev/null +++ b/kexec-tools-2.0.4-makedumpfile-disable-mmap.patch @@ -0,0 +1,36 @@ +makedumpfile: disable mmap read + +There's a kernel bug for mapping mem ranges which end with +an address not aligned to page boundry. It's still not resolved +in upstream, so let's disable mmap read for now as a workaround. + +Once upstream got a right fix we can revert this patch. + +Signed-off-by: Dave Young <dyoung(a)redhat.com> +--- + makedumpfile.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- kexec-tools/makedumpfile-1.5.4/makedumpfile.c.orig ++++ kexec-tools/makedumpfile-1.5.4/makedumpfile.c +@@ -3144,6 +3144,12 @@ out: + if (info->dump_level & DL_EXCLUDE_FREE) + setup_page_is_buddy(); + ++ /* There's a kernel bug for mapping mem ranges which end with ++ * an address not aligned to page boundry. It's still not resolved ++ * in upstream, so let's disable mmap read for now. ++ */ ++ info->flag_usemmap = FALSE; ++#if 0 + if (!initialize_mmap()) { + /* this kernel does not support mmap of vmcore */ + DEBUG_MSG("Kernel can't mmap vmcore, using reads.\n"); +@@ -3152,6 +3158,7 @@ out: + DEBUG_MSG("read %s with mmap()\n", info->name_memory); + info->flag_usemmap = TRUE; + } ++#endif + + return TRUE; + } diff --git a/kexec-tools.spec b/kexec-tools.spec index 5845b21..4182906 100644 --- a/kexec-tools.spec +++ b/kexec-tools.spec @@ -88,6 +88,7 @@ Patch607: kexec-tools-2.0.4-makedumpfile-Update-pfn_cyclic-when-the-cyclic-buffe Patch608: kexec-tools-2.0.4-makedumpfile-Use-divideup-to-calculate-maximum-required-bit.patch Patch609: kexec-tools-2.0.4-makedumpfile-cache-Allocate-buffers-at-initialization-t.patch Patch610: kexec-tools-2.0.4-makedumpfile-cache-Reuse-entry-in-pending-list.patch +Patch611: kexec-tools-2.0.4-makedumpfile-disable-mmap.patch %description kexec-tools provides /sbin/kexec binary that facilitates a new @@ -126,6 +127,7 @@ tar -z -x -v -f %{SOURCE19} %patch608 -p1 %patch609 -p1 %patch610 -p1 +%patch611 -p1 %patch001 -p1 %patch002 -p1 %patch003 -p1

2 1

[patch 0/6] kexec kernel efi runtime support
by Dave Young 01 Nov '13

01 Nov '13

Hi, Here is the 1st version for supporting kexec kernel efi runtime. Per pervious discussion I pass the 1st kernel efi runtime mapping via setup_data to 2nd kernel. Besides of the runtime mapping info I also pass the fw_vendor, runtime, config table, smbios physical address in setup_data. EFI spec mentioned fw_vendor, runtime, config table addresses will be converted to virt address after entering virtual mode, but we will use it as physical address in efi_init. For smbios EFI spec did not mention about the address updating, but during my test on a HP workstation, the bios will convert it to Virt addr, thus pass it in setup_data as well. For fw_vendor, runtime, config table, I export them in /sys/firmware/ efi/systab, smbios is already in that file. For efi runtime mapping I add a new directory /sys/firmware/efi/ efi-runtime-map/ like below [dave@darkstar ~]$ tree /sys/firmware/efi/efi-runtime-map/ /sys/firmware/efi/efi-runtime-map/ ├── 0 │ ├── attribute │ ├── num_pages │ ├── phys_addr │ ├── type │ └── virt_addr ├── 1 │ ├── attribute │ ├── num_pages │ ├── phys_addr │ ├── type │ └── virt_addr [snip] kexec-tools will assemble them as setup_data and pass to 2nd kernel. I will send userspace patches as well. Limitation is I only write support for x86_64, test on below machines: Lenovo thinkpad t420 Dell inspiron 14 - 3421 HP Z420 workstation Qemu + OVMF Please help to review the patches. The patches are based on linus tree (3.12.0-rc6+) + matt's next tree + bp's efi mapping patches Boris's last patch can not directly apply, need a little line shifting. -- Thanks Dave

5 36

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

kexec November 2013