Commit Graph

724 Commits

Author SHA1 Message Date
Baoquan He
1065b91f7d Add acpi_no_memhotplug to kdump kernel
In kdump kernel boot, kdump kernel is booted with memmap= and add
them into e820 map. Then ACPI is initialized and the kernel traverses
the ACPI namespace to find entries for memory device to be hot added.
This adds page table information and the kexec/kdump kernel runs out
of memory.

So in kdump kernel, hot plug memory need be disabled always, only
exact map is trusted. Now add the kernel parameter acpi_no_memhotplug
to kdump kernel cmdline.

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-01-29 16:25:57 +08:00
WANG Chao
11cb815904 module-setup.sh: do not add duplicate ip=xxx to 40ip.conf
In the remote dump case, and if fence kdump is configured, chances are
that the same network interface will be setup more than once.
One time for network dump, the other times for fence kdump. The result
is we will have two or more duplicate ip= configuration in 40ip.conf.

These are exactly duplicates, however dracut will refuse to continue and
raise a fatal error if there are duplicate configuration for the same
interface. So we have to avoid adding these duplicates.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Tested-by: Zhi Zou <zzou@redhat.com>
Tested-by: Marek Grac <mgrac@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-01-29 16:20:06 +08:00
WANG Chao
da61e30907 module-setup.sh: setup fence kdump environment
This patch is used to setup fence kdump environment when building kdump
initrd:
1. Check if it's cluster and fence_kdump is configured.
2. Get all the nodes in the cluster and pass them to 2nd kernel via
   /etc/fence_kdump_nodes
3. Setup network interface which will be used by fence kdump notifier in
   2nd kernel.
4. Install fence kdump notifier (/usr/libexec/fence_kdump_send) to
   initrd.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Tested-by: Zhi Zou <zzou@redhat.com>
Tested-by: Marek Grac <mgrac@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-01-29 16:20:06 +08:00
WANG Chao
e5e0507371 kdump.sh: send fence kdump message to other nodes in the cluster
In 2nd kernel, to prevent the crashed system from being fenced off,
fence kdump message must be send to other nodes in the cluster
periodically before dumping process.

We preserve every node's name in /etc/fence_kdump_nodes in the
initrd, so we parse this file and send notify them.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Tested-by: Zhi Zou <zzou@redhat.com>
Tested-by: Marek Grac <mgrac@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-01-29 16:20:06 +08:00
WANG Chao
590a0c21ab kdumpctl: rebuild kdump initramfs if cluster or fence_kdump config is changed.
If the system is configured fence kdump, we need to update kdump
initramfs if cluster or fence_kdump config is newer.

In RHEL7, cluster config is no longer keeping locally but stored
remotely. Fortunately we can use a pcs tool to retrieve the xml based
config and parse the last changed time from that.

/etc/sysconfig/fence_kdump is used to configure runtime arguments to
fence_kdump_send. So We have to pass the arguments to 2nd kernel.

When cluster config or /etc/sysconfig/fence_kdump is newer than local
kdump initramfs, we must rebuild initramfs to adapt changes in cluster.

For example:

Detected change(s) the following file(s):

  cluster-cib /etc/sysconfig/fence_kdump
Rebuilding /boot/initramfs-xxxkdump.img
[..]

Signed-off-by: WANG Chao <chaowang@redhat.com>
Tested-by: Zhi Zou <zzou@redhat.com>
Tested-by: Marek Grac <mgrac@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-01-29 16:20:06 +08:00
WANG Chao
b0535afe2d kdump-lib: add common variables and function for fence kdump
Add following common variables and function:

$FENCE_KDUMP_CONIFG: configuration file /etc/sysconfig/fence_kdump
$FENCE_KDUMP_NODES: configuration file /etc/fence_kdump_nodes
$FENCE_KDUMP_SEND: executable /usr/libexec/fence_kdump_send
is_fence_kdump(): used to determine if the system is in a cluster and
configured with fence_kdump.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Tested-by: Zhi Zou <zzou@redhat.com>
Tested-by: Marek Grac <mgrac@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-01-29 16:20:06 +08:00
arthur
11bb4785f8 Add a kdump-in-cluster-environment.txt in RPM package
Since kdump already support dump in cluster environment, this patch
add a howto file to RPM package to describe how to configure kdump
in cluster environment.

Signed-off-by: arthur <zzou@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-01-29 16:20:06 +08:00
WANG Chao
5d68494023 Release 2.0.4-22
Signed-off-by: WANG Chao <chaowang@redhat.com>
2014-01-28 13:07:09 +08:00
WANG Chao
6ae85f33a7 Rebase makedumpfile-1.5.5
Signed-off-by: WANG Chao <chaowang@redhat.com>
2014-01-28 13:04:36 +08:00
WANG Chao
59b1229661 Release 2.0.4-21
Signed-off-by: WANG Chao <chaowang@redhat.com>
2014-01-22 12:53:36 +08:00
WANG Chao
5c134fbd0d s390x, sysconfig: Change maxcpus=1 to nr_cpus=1 for s390x
IBM would strongly recommend for s390x to replace "maxcpus=1" with
"nr_cpus=1" because with the "nr_cpus=1" kernel parameter only for one
CPU the per-cpu data structures are allocated. This currently saves
several MiB of memory.

IBM (michael.holzheu@de.ibm.com) has confirmed this patch worked fine.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-01-22 12:52:02 +08:00
Baoquan He
b085004c23 makedumpfile: Improve progress information for huge memory system.
Backport from upstream.

commit 20ecc0827e7837c52f3903638a59959f8bf17f9e
Author: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Date:   Tue Nov 5 00:29:35 2013 +0900

    [PATCH v2] Improve progress information for huge memory system.

    On system with huge memory, percentage in progress information is
    updated at very slow interval, because 1 percent on 1 TiB memory is
    about 10 GiB, which looks like as if system has freezed. Then,
    confused users might get tempted to push a reset button to recover the
    system. We want to avoid such situation as much as possible.

    Signed-off-by: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-01-22 12:52:01 +08:00
WANG Chao
e14ca722e8 Release 2.0.4-20
Signed-off-by: WANG Chao <chaowang@redhat.com>
2014-01-17 11:50:17 +08:00
WANG Chao
6752e5562e vmcore-dmesg: struct_val_u64() not casting u64 to u32
This is a backport of the following upstream commit:

commit 158d763
Author: WANG Chao <chaowang@redhat.com>
Date:   Tue Jan 7 01:37:34 2014 +0800

    vmcore-dmesg: struct_val_u64() not casting u64 to u32

    It seems gcc doesn't check return type from inline function.
    struct_val_u64() should return u64 otherwise upper 32bit is lost.

    Signed-off-by: WANG Chao <chaowang@redhat.com>
    Acked-by: Vivek Goyal <vgoyal@redhat.com>
    Signed-off-by: Simon Horman <horms@verge.net.au>

timestamp in vmcore-dmesg is u64 type but it's truncated to u32, which
results in wrong time stamp. So let's backport this patch to fix this
issue.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-01-17 11:32:48 +08:00
WANG Chao
dd7eee7e4a makedumpfile: Fall back to read() when mmap() fails
This is a backport of the following upstream commit:

commit 7c770ed
Author: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Date:   Thu Dec 12 16:40:31 2013 +0900

    [PATCH] Fall back to read() when mmap() fails.

    This is a fall back path for mmap().
    This patch disables mmap() when facing the issues related to mmap(),
    and read() will be used to read vmcore instead.

    Signed-off-by: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>

mmap() file operation on vmcore is working properly when the page being
accessed has different attributes on different part (ie. two different type
of memory ranges are overlapping).

A fall back mechanism is introduced in this patch, in case mmap() fails,
switch to read() afterwards.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-01-17 11:32:48 +08:00
WANG Chao
89a4cb24e0 makedumpfile: Add --non-mmap option to disable mmap() manually
This is a backport of the following upstream commit:

commit a895dc8
Author: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
Date:   Thu Dec 12 16:40:12 2013 +0900

    [PATCH] Add --non-mmap option to disable mmap() manually.

    When --non-mmap option is specified, makedumpfile doesn't use
    mmap() even if /proc/vmcore supports mmap().

    Signed-off-by: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>

Having this patch, user can switch between mmap() and read() when
accessing vmcore. Whenever user feels necessary to use readmem on vmcore
(buggy code in mmap path, debug purpose, etc.), --non-mmap can do this
favor.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-01-17 11:32:48 +08:00
WANG Chao
778ab7d0c4 makedumpfile: Add help and man message for '--help'
This is a backport  of the following upstream commit:

commit eb708ce
Author: Baoquan He <bhe@redhat.com>
Date:   Tue Jul 2 11:11:07 2013 +0900

    [PATCH 2/2] Add help and man message for '--help'.

    Conventionally '-h' and '--help' are all provided. Currently makedumpfile
    lacks help and man message for '--help'. Here add it.

    Signed-off-by: Baoquan He <bhe@redhat.com>

It's needed for applying commit 414d3ed ("Add --non-mmap option to
disable mmap() manually").

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-01-17 11:32:47 +08:00
WANG Chao
194a389a9f makedumpfile: Assign non-printable value as short options
This is a backport of the following upstream commit:

commit bd67c1d
Author: Baoquan He <bhe@redhat.com>
Date:   Tue Jul 2 11:09:20 2013 +0900

    [PATCH 1/2] Assign non-printable value as short options.

    Characters for short options is limited, and now makedumpfile has
    considerably many options. As times go on, no enough reasonable
    letters can be assigned to each functionality with short options.

    E.g non-cyclic vs Y, cyclic-buffer vs Z, eppic vs S.

    Now assign non-printable value to these kind of short optins, meanwhile
    define them as indicative MACRO which can make code more readable.

    Signed-off-by: Baoquan He <bhe@redhat.com>

It's needed for applying commit 414d3ed ("Add --non-mmap option to
disable mmap() manually").

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-01-17 11:32:47 +08:00
WANG Chao
bad556cf2e makedumpfile: Revert "makedumpfile: disable mmap"
This reverts commit 2dc9600ad1:

commit 2dc9600
Author: Dave Young <dyoung@redhat.com>
Date:   Thu Nov 14 10:51:47 2013 +0800

    makedumpfile: disable mmap

    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@redhat.com>

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-01-17 11:32:47 +08:00
WANG Chao
9b0f728d92 kdump.conf: uncomment default core_collector line
Having uncommented core_collector line in default kdump.conf would help
s-c-kdump determine which arguments to use without relying on hardcoded
values.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-01-17 11:32:47 +08:00
WANG Chao
cdde81ddbd ssh: use ssh -n to redirect stdin from /dev/null
When we're parsing kdump.conf, we read it from stdin in a while
loop statement. If we don't use ssh -n within the loop, all rest of the
kdump.conf options, which are in stdin, will be eaten by ssh.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2014-01-17 11:32:47 +08:00
WANG Chao
0e90b05d96 Release 2.0.4-18
Signed-off-by: WANG Chao <chaowang@redhat.com>
2013-12-24 14:37:13 +08:00
WANG Chao
e69a557c76 Translation, Makefile: add make tgz option to auto pack po files
make tgz now will automatically pack the po files and Makefile to
kexec-tools-po-`date +%Y%m%d`.tgz to make life easier when we update po
files.

Signed-off-by: WANG Chao <chaowang@redhat.com>
2013-12-24 14:25:23 +08:00
WANG Chao
1537e3ae88 Translation update
The following po files are updated:
bn_IN.po
es.po
gu.po
it.po

Signed-off-by: WANG Chao <chaowang@redhat.com>
2013-12-24 14:25:20 +08:00
WANG Chao
9f7ba60b3b Translation: rename ta-IN.po to ta_IN.po
The locale directory for Tamil (India) is
"/usr/share/locale/ta_IN/LC_MESSAGES/" but not
"/usr/share/locale/ta-IN/LC_MESSAGES/"

For the locale directory mapping purpose, need to change ta-IN to ta_IN:

$ git mv ta-IN.po ta_IN.po

Signed-off-by: WANG Chao <chaowang@redhat.com>
2013-12-24 14:25:18 +08:00
WANG Chao
7d6ef48a5a Add makedumpfile.conf and its man page
makedumpfile can filter out kernel data from vmcore[1]. A how-to of feature
is well explained in makedumpfile.conf, which upstream is already
shipping but we're not.

Now add makedumpfile.conf and its man page to our package the upstream
way:

makedumpfile.conf --> /etc/makedumpfile.conf.sample
makedumpfile.conf.5.gz --> /usr/share/man/man5/makedumpfile.conf.5.gz

[1]. http://lists.infradead.org/pipermail/kexec/2011-September/005466.html

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-12-24 14:25:11 +08:00
WANG Chao
fac2d59ae4 makedumpfile compression method default to lzo
Lzo is proven faster than zlib, for large memory machine it will
extremely shorten the time for saving vmcore. Let's switch to lzo as the
default compression method for makedumpfile.

The drawback is lzo has a little less compression ratio than zlib. But
considering for most users, speed/time is a more serious concern than
vmcore size. So I think default to lzo will benefit most of the users.

v1->v2: update kdump.conf.5 [DaveY]

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2013-12-24 14:25:07 +08:00
Ville Skyttä
3b60d01930 Drop period at end of Summary. 2013-12-21 23:26:12 +02:00
Ville Skyttä
9017c32c77 Fix Tamil (India) locale subdir name.
- Fix bogus date in %changelog.
2013-12-21 23:25:08 +02:00
WANG Chao
ce5e13266e Release 2.0.4-14
Signed-off-by: WANG Chao <chaowang@redhat.com>
2013-12-03 11:32:04 +08:00
WANG Chao
b82449261b makedumpfile, ppc: Support to filter dump for kernels that use CONFIG_SPARSEMEM_VMEMMAP.
This is a backport of commit bcdba92 ("[PATCH v5] Support to filter dump
for kernels that use CONFIG_SPARSEMEM_VMEMMAP."):

commit bcdba92
Author: Hari Bathini <hbathini@linux.vnet.ibm.com>
Date:   Mon Nov 25 17:20:55 2013 +0900

    [PATCH v5] Support to filter dump for kernels that use CONFIG_SPARSEMEM_VMEMMAP.

    Makedumpfile tool fails to filter dump for kernels that are build with
    CONFIG_SPARSEMEM_VMEMMAP set, as it fails to do address translations
    for vmemmap regions that are mapped out of zone normal. This patch
    provides support in makedumpfile to do vmemmap to physical address
    translations when they are mapped outside zone normal. Some kernel
    symbols are needed in vmcoreinfo for this changes to be effective.
    The kernel patch that adds the necessary symbols to vmcoreinfo has
    been posted to linuxppc devel mailing list. This patch is influenced
    by vmemmap to physical address translation support code in crash tool.
    This patch has been tested successfully at all dump filtering levels
    on kernels with CONFIG_SPARSEMEM_VMEMMAP set/unset. Also, tested dump
    filtering on already filtered vmcores (re-filtering).

    Changes from v4 to v5:
    Trimmed patch description to be compact and readable.

    Changes from v3 to v4:
    Rebased to devel branch.

    Signed-off-by: Onkar N Mahajan <onmahaja@in.ibm.com>
    Signed-off-by: Hari Bathini <hbathini@linux.vnet.ibm.com>

On PPC platform, filter facility is broken since we use
CONFIG_SPARSEMEM_VMEMMAP. This patch fixes this issue but also needs kernel
counterpart fix to get makedumpfile filter working.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Steve Best<sbest@redhat.com>
2013-11-28 11:39:20 +08:00
WANG Chao
296e8d3779 makedumpfile: Understand >= v3.11-rc4 dmesg.
This is a backport of commit a01b663 ("[PATCH v2] dump-dmesg: Understand
>= v3.11-rc4 dmesg."):

commit a01b663
Author: Lubomir Rintel <lkundrak@v3.sk>
Date:   Fri Sep 20 15:56:49 2013 +0900

    [PATCH v2] dump-dmesg: Understand >= v3.11-rc4 dmesg.

    Symbol name changed with the following commit:
    62e32ac printk: rename struct log to struct printk_log

    Changes for v2:
      * Only back values for symbol names we did actually read;
      *         either "log" or "printk_log"

    Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>

makedumpfile --dump-dmesg is broken since VMCOREINFO symbol "log" has
renamed to "printk_log". This patch fixes --dump-dmesg on 3.11 kernel.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-11-28 11:39:20 +08:00
WANG Chao
59934ba188 kdumpctl: Avoid leaking fd to subshell
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@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-11-28 11:39:20 +08:00
arthur
ef9f97dcad Add rd.memdebug in kdump module
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.

Signed-off-by: arthur <zzou@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2013-11-28 11:39:18 +08:00
WANG Chao
376a899b09 Release 2.0.4-13
Signed-off-by: WANG Chao <chaowang@redhat.com>
2013-11-15 13:34:11 +08:00
Dave Young
2dc9600ad1 makedumpfile: disable mmap
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@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-11-15 13:32:20 +08:00
WANG Chao
c9bc5ca307 Release 2.0.4-12
Signed-off-by: WANG Chao <chaowang@redhat.com>
2013-10-29 13:44:52 +08:00
arthur
d43f2a8502 fix sadump format phys_base calculating error
Description of Problem:

  This is a REGRESSION issue.

  At fedora makedumpfile has been updated toward v1.5.4. Unfortunately,
  this version fails calculating phys_base on sadump format and then
  fails converting vmcore.

  x86_64 kernel is relocatable kernel and there can be a gap between
  the physical address statically assigned to kernel data and texts
  and the address that is really assigned to each object corresponding
  to the kernel symbols. The gap is phys_base. makedump calculates the
  phys_base in an ad-hoc way that comparing the addresses of some of
  occurrences of "Linux kernel" strings in certain range of vmcore.

Resolution:
  Fix patch has already been posted in upstream. so just back port.
  The commit ID are:
  commit e23dc0a1aa5fa7a4429f72ff1c2fe87a87291065
  commit 92563d7a7a5175ef78c4a94ee269b1b455331b4c

Signed-off-by: arthur <zzou@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-10-29 13:28:26 +08:00
WANG Chao
bb3f341fb2 kdump, x86: Process multiple Crash kernel in /proc/iomem
Boot with "crashkernel=128M,high", kernel now uses "Crash kernel" in
/proc/iomem for crash kernel memory reservations at both low and high:

commit 157752d
Author: Yinghai Lu <yinghai@kernel.org>

    kexec: use Crash kernel for Crash kernel low

But kexec is still scanning for "Crash kernel low" in /proc/iomem, and
will fail immediately when load/unload crash kernel.

So let's pull the following commit from kexec upstream to make
it compatible with our kernel:

commit e25e6e7
Author: Yinghai Lu <yinghai@kernel.org>

    kdump, x86: Process multiple Crash kernel in /proc/iomem

(This patch from upstream is untouched and can be applied cleanly)

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-10-29 13:17:31 +08:00
Baoquan He
55c7158d16 makedumpfile: wrong cyclic buffer size recalculation causes bitmap data corruption
Description of Problem:

In cyclic mode, makedumpfile recalculates cyclic buffer size as the
largest multiple of the largest block size managed by buddy
allocator, i.e. 4MB, smaller than the cyclic buffer size in order to
enable to process each unit of blocks managed by buddy allocator in
each cycle.

However, makedumpfile does two wrong things in the recalculations:

1) While updating size of cyclic buffer, makedumpfile doesn't update
length of range of cycle in page frame numbers, due to which, if
cyclic buffer size is updated, because cyclic buffer size is always
reduced during udpate, some buffer overrun can happen on the cyclic
buffer. This can cause segmentation violation in the worst case.

2) roundup() is used to calculate bitmap size for maximum block size
managed by buddy allocator, here divideup() is correct, due to
which, although memory filtering is not affected, cyclic buffer size
get too much aligned and less efficient.

Fix patches has already been posted and merged in makedumpfile
development devel branch.

git://git.code.sf.net/p/makedumpfile/code
f8c8218856effc43ea01cd9394761cfb8aeaa8df
a785fa7dd7a7bd7dcbb017d0bea8848243b0924f

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
2013-10-29 13:15:46 +08:00
Baoquan He
6a56c56743 Fix max_mapnr issue on system has over 44-bit addressing.
The dumpfile header has this field, which was inherited from
the old "diskdump" facility:

 struct disk_dump_header {
 ...
        unsigned int            max_mapnr;      /* = max_mapnr */
 ...
and which, among other things, is used by the crash utility as a
delimiter to determine whether a physical address read request is
legitimate.  And obviously the field cannot handle PFN values greater
than 32-bits.

The makedumpfile source code does have its own max_mapnr representation
in its DumpInfo structure in "makedumpfile.h":

 struct DumpInfo {
 ...
        unsigned long long      max_mapnr;   /* number of page descriptor */
 ...
But in its "diskdump_mod.h" file, it carries forward the old diskdump
header format, which has the 32-bit field:

 struct disk_dump_header {
 ...
        unsigned int            max_mapnr;      /* = max_mapnr */
 ...
And here in "makedumpfile.c", the inadvertent truncation occurs
when the PFN is greater than 32-bits:

 int
 write_kdump_header(void)
 {
 ...
        dh->max_mapnr      = info->max_mapnr;
 ...
Now upstream has below commit to fix this, back port it:

commit 8e124174b62376b17ac909bc68622ef07bde6840
Author: Jingbai Ma <jingbai.ma@hp.com>
Date:   Fri Oct 18 18:53:38 2013 +0900

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
2013-10-28 17:33:16 +08:00
Baoquan He
daf4abdeeb Release 2.0.4-11 2013-10-12 16:05:43 +08:00
Baoquan He
a682315996 kdump-lib.sh: strip_comments is not implemented correcty
In mkdumprd, strip_comments is not implemented correctly. Since arguments
passed, strip_comments only take $1 and misses others. This caused
problems. Such as below line, current code will only get "makedumpfile"
and pass it to $config_val finally, then parameters for makedumpfile
are missed.

core_collector makedumpfile -c --message-level 1 -d 31

Now modify function strip_comments.

Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: WANG Chao <chaowang@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2013-10-12 16:00:12 +08:00
Baoquan He
514be15bf4 Release 2.0.4-10 2013-09-27 17:15:02 +08:00
Baoquan He
377b01b270 Back port 2 revert commits
In 2.0.4, Cliff from HP posted 2 patches:
e35aa29 kexec: include reserved e820 sections in crash kernel
4932034 kexec: lengthen the kernel command line image

However, with both of them kdump kernel may fail to boot, and
are useless because of restriction in kernel side. In upstream,
they have been reverted. Now back port these 2 revert commits.
Also since the commit 1a4e90b has dependency, back port commit
dc607e4 which is depended on by commit 1a4e90b too.

1a4e90b Revert "kexec: include reserved e820 sections in crash kernel"
dc607e4 kexec: i386: Add cmdline_add_memmap_internal() to reduce the code duplication
8274916 Revert: "kexec: lengthen the kernel command line image"
2013-09-27 17:01:24 +08:00
WANG Chao
7c48f71b6f kdump.sysconfig: default to "nofail" mount
Currently we have two issues against mounting filesystems by systemd.
1. If any failure in sysroot.mount, initrd.target won't be reached.
2. If any failure in mounting /etc/fstab, initrd.target won't be reached

Our kdump.sh is in dracut-pre-pivot hook which is ordered after
initrd.target. That means if systemd doesn't reach initrd.target,
pre-pivot service will not run.

Based on above, we can conclude that in order to run kdump.sh,
initrd.target must be reached.

To fix issue 1), we can add rootflags=nofail to 2nd kernel cmdline, so
that initrd.target will not require sysroot.mount. initrd.target
wouldn't care about the failures in sysroot.mount. That means
initrd.target can always be reached whether or not sysroot.mount fails.
So when initrd.target is reached, kdump.sh can be run.

To fix issue 2), we can append "nofail" mount options to every entry in
/etc/fstab. It has almost the same affects as to sysroot.mount.
initrd.target can be reached whether or not mount /etc/fstab fails. So
when initrd.target is reached, kdump.sh can be run.

If the mount failures block kdump from working properly (for example,
the dump target isn't mounted), the error handling will be done by
"default" action specified in /etc/kdump.conf. Otherwise kdump will
ignore the mount failures and dump as expected.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
2013-09-27 15:45:24 +08:00
Baoquan He
45f24f53f5 Release 2.0.4-9 2013-09-27 10:18:06 +08:00
Baoquan He
59e28ddf75 Strip inline comments from the kdump config file before use
From: Wade Mealing <wmealing@redhat.com>

The RHEL 5 release of mkdumprd allowed for comments in the kdump config
file as shown below:

net 192.168.1.1 # this is the comment part

This patch strips them out during processing, but leaves the configuration
file in original condition.

Signed-off-by: Wade Mealing <wmealing@redhat.com>
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-09-27 10:09:25 +08:00
Baoquan He
ee524473c8 kdump-lib.sh: add common function strip_comments
Add function strip_comments into kdump-lib.sh, since it's used by
several files.

Signed-off-by: Wade Mealing <wmealing@redhat.com>
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-09-27 10:08:56 +08:00
WANG Chao
a8921f04ae Introduce kdump-lib.sh for kdump shared functions
Currently in the whole kdump framework, we have some common functions
used across not only mkdumprd context and dracut context, but also 1st
kernel and 2nd kernel. We defined these functions at each script, which
is obviously not decent.

So let's introduce kdump-lib.sh for the shared functions and put it
to /lib/kdump/kdump-lib.sh.

It starts small, as you can see, only 3 functions are extracted. But in
the future more and more common functions can be added.

Signed-off-by: WANG Chao <chaowang@redhat.com>
Acked-by: Vivek Goyal <vgoyal@redhat.com>
2013-09-27 10:07:13 +08:00