[PATCH 0/2] two backports for makedumpfile
by WANG Chao
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
10 years
[PATCH] kdumpctl: Avoid leaking fd to subshell
by WANG Chao
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
10 years
crash on F20 beta says log_buf data structure has changed
by Vivek Goyal
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
10 years
[PATCH] Add rd.memdebug in kdump module
by Arthur Zou
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
10 years
[PATCH] makedumpfile: disable mmap
by Dave Young
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
10 years
[patch 0/6] kexec kernel efi runtime support
by Dave Young
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
10 years, 1 month