Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
by tachibana＠mxm.nes.nec.co.jp
Hi Hatayama-san,
On 2011/06/29 12:12:18 +0900, HATAYAMA Daisuke <d.hatayama(a)jp.fujitsu.com> wrote:
> From: Dave Anderson <anderson(a)redhat.com>
> Subject: Re: [Crash-utility] [RFI] Support Fujitsu's sadump dump format
> Date: Tue, 28 Jun 2011 08:57:42 -0400 (EDT)
>
> >
> >
> > ----- Original Message -----
> >> Fujitsu has stand-alone dump mechanism based on firmware level
> >> functionality, which we call SADUMP, in short.
> >>
> >> We've maintained utility tools internally but now we're thinking that
> >> the best is crash utility and makedumpfile supports the sadump format
> >> for the viewpoint of both portability and maintainability.
> >>
> >> We'll be of course responsible for its maintainance in a continuous
> >> manner. The sadump dump format is very similar to diskdump format and
> >> so kdump (compressed) format, so we estimate patch set would be a
> >> relatively small size.
> >>
> >> Could you tell me whether crash utility and makedumpfile can support
> >> the sadump format? If OK, we'll start to make patchset.
I think it's not bad to support sadump by makedumpfile. However I have
several questions.
- Do you want to use makedumpfile to make an existing file that sadump has
dumped small?
- It isn't possible to support the same form as kdump-compressed format
now, is it?
- When the information that makedumpfile reads from a note of /proc/vmcore
(or a header of kdump-compressed format) is added by an extension of
makedumpfile, do you need to modify sadump?
Thanks
tachibana
> >
> > Sure, yes, the crash utility can always support another dumpfile format.
> >
>
> Thanks. It helps a lot.
>
> > It's unclear to me how similar SADUMP is to diskdump/compressed-kdump.
> > Does your internal version patch diskdump.c, or do you maintain your
> > own "sadump.c"? I ask because if your patchset is at all intrusive,
> > I'd prefer it be kept in its own file, primarily for maintainability,
> > but also because SADUMP is essentially a black-box to anybody outside
> > Fujitsu.
>
> What I meant when I used ``similar'' is both literally and
> logically. The format consists of diskdump header-like header, two
> kinds of bitmaps used for the same purpose as those in diskump format,
> and memory data. They can be handled in common with the existing data
> structure, diskdump_data, non-intrusively, so I hope they are placed
> in diskdump.c.
>
> On the other hand, there's a code to be placed at such specific
> area. sadump is triggered depending on kdump's progress and so
> register values to be contained in vmcore varies according to the
> progress: If crash_notes has been initialized when sadump is
> triggered, sadump packs the register values in crash_notes; if not
> yet, packs registers gathered by firmware. This is sadump specific
> processing, so I think putting it in specific sadump.c file is a
> natural and reasonable choise.
>
> Anyway, I have not made any patch set for this. I'll post a patch set
> when I complete.
>
> Again, thanks a lot for the positive answer.
>
> Thanks.
> HATAYAMA, Daisuke
>
>
> _______________________________________________
> kexec mailing list
> kexec(a)lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
7 months, 2 weeks
add print raw data capability for rd
by Lei Wen
Hi,
I recent make a patch which give the rd command to dump the raw data. With this,
we could then do the dump the specified range of memory to the file
with console's
redirection feature like: rd -r 0x7000000 -e 0x8000000 > dump.img.
What about this idea? Could it be accepted?
Thanks,
Lei
>From f60eee5520993d823cf705ecea62b8d60166f3ae Mon Sep 17 00:00:00 2001
From: Lei Wen <leiwen(a)marvell.com>
Date: Thu, 29 Sep 2011 20:03:29 -0700
Subject: [PATCH] rd: add option to dump the raw format
Signed-off-by: Lei Wen <leiwen(a)marvell.com>
---
help.c | 3 ++-
memory.c | 13 ++++++++++++-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/help.c b/help.c
index b8db00a..987bd95 100755
--- a/help.c
+++ b/help.c
@@ -1396,7 +1396,7 @@ NULL
char *help_rd[] = {
"rd",
"read memory",
-"[-adDsSupxmfN][-8|-16|-32|-64][-o offs][-e addr] [address|symbol] [count]",
+"[-adDsSupxrmfN][-8|-16|-32|-64][-o offs][-e addr] [address|symbol] [count]",
" This command displays the contents of memory, with the output formatted",
" in several different manners. The starting address may be entered either",
" symbolically or by address. The default output size is the size of a long",
@@ -1426,6 +1426,7 @@ char *help_rd[] = {
" non-printable character.",
" -N display output in network byte order (only valid for 16-
and 32-bit",
" values)",
+" -r dump the address as raw format",
" -o offs offset the starting address by offs.",
" -e addr display memory until reaching specified ending
hexadecimal address.",
" address starting hexadecimal address:",
diff --git a/memory.c b/memory.c
index 9575d8e..985e2ec 100755
--- a/memory.c
+++ b/memory.c
@@ -264,6 +264,7 @@ static void dump_page_flags(ulonglong);
#define SLAB_CACHE (0x1000)
#define DISPLAY_ASCII (0x2000)
#define NET_ENDIAN (0x4000)
+#define DISPLAY_RAW (0x8000)
#define DISPLAY_TYPES
(DISPLAY_ASCII|DISPLAY_8|DISPLAY_16|DISPLAY_32|DISPLAY_64)
#define ASCII_UNLIMITED ((ulong)(-1) >> 1)
@@ -973,9 +974,12 @@ cmd_rd(void)
memtype = KVADDR;
count = -1;
- while ((c = getopt(argcnt, args, "axme:pfudDusSNo:81:3:6:")) != EOF) {
+ while ((c = getopt(argcnt, args, "raxme:pfudDusSNo:81:3:6:")) != EOF) {
switch(c)
{
+ case 'r':
+ flag |= DISPLAY_RAW;
+ break;
case 'a':
flag &= ~DISPLAY_TYPES;
flag |= DISPLAY_ASCII;
@@ -1291,6 +1295,13 @@ display_memory(ulonglong addr, long count,
ulong flag, int memtype)
for (i = a = 0; i < count; i++) {
readmem(addr, memtype, location, typesz,
readtype, FAULT_ON_ERROR);
+ if (flag & DISPLAY_RAW) {
+ for (j = 0; j < typesz; j++)
+ fputc(*(char *)(location + j), fp);
+
+ addr += typesz;
+ continue;
+ }
if (!(flag & DISPLAY_ASCII) && ((i % per_line) == 0)) {
if (i) {
--
1.7.0.4
12 years, 8 months
Crash faults when determining panic task
by Lawrence, Joe
I have a vmcore generated on RHEL6.1 that newer versions of crash have
trouble analyzing (5.1.1-2.el6 seems to work ok).
I can provide additional binary files if needed, just let me know what
convention best suits the list (ftp, private email attachment, etc.)
Crash Version: OS: Result:
crash 5.1.8 Debian wheezy faults
crash 5.1.7-1.el6 RHEL6.2 Alpha faults
crash 5.1.1-2.el6 RHEL6.1 ok
Kernel:
2.6.32-131.0.15.el6.exp10.bz16586.x86_64 (2.6.32-131.0.15 + a fix for
Red Hat bz-707268)
Interesting warnings when starting crash:
WARNING: sparsemem: invalid section number: 137438888923
WARNING: sparsemem: invalid section number: 137438888923
First fault, null pointer deference:
please wait... (determining panic task)
Program received signal SIGSEGV, Segmentation fault.
x86_64_get_dumpfile_stack_frame (rsp=0x7fffffffcc58, rip=0x7fffffffcc50,
bt_in=0x7fffffffcce0) at x86_64.c:4183
4183 ur_rip = ULONG(user_regs +
(gdb) p user_regs
$1 = 0x0
Workaround, check that bt->machdep is not NULL:
diff -Nupr crash-5.1.8/x86_64.c crash-5.1.8.new/x86_64.c
--- crash-5.1.8/x86_64.c 2011-09-16 15:01:12.000000000 -0400
+++ crash-5.1.8.new/x86_64.c 2011-09-28 14:12:45.347188571 -0400
@@ -4178,7 +4178,7 @@ x86_64_get_dumpfile_stack_frame(struct b
goto skip_stage;
}
}
- } else if (ELF_NOTES_VALID()) {
+ } else if (ELF_NOTES_VALID() && bt->machdep) {
user_regs = bt->machdep;
ur_rip = ULONG(user_regs +
OFFSET(user_regs_struct_rip));
Second fault, a curiously large n_descsz in elf note header:
please wait... (determining panic task)
Program received signal SIGSEGV, Segmentation fault.
get_regs_from_note (note=0xd26472 "\b", ip=0x7fffffffc4e0,
sp=0x7fffffffc4e8)
at netdump.c:2221
2221 *sp = ULONG(user_regs + offset_sp);
(gdb) p *(Elf64_Nhdr *)note
$1 = {n_namesz = 8, n_descsz = 3438804992, n_type = 8}
Workaround, do not attempt reading registers from elf notes (this chunk
of code was not present in crash 5.1.1):
diff -Nupr crash-5.1.8/netdump.c crash-5.1.8.new/netdump.c
--- crash-5.1.8/netdump.c 2011-09-16 15:01:12.000000000 -0400
+++ crash-5.1.8.new/netdump.c 2011-09-28 14:14:43.687183734 -0400
@@ -2286,7 +2286,7 @@ get_netdump_regs_x86_64(struct bt_info *
bt->machdep = (void *)user_regs;
}
-
+#if 0
if (ELF_NOTES_VALID() &&
(bt->flags & BT_DUMPFILE_SEARCH) && DISKDUMP_DUMPFILE() &&
(note = (Elf64_Nhdr *)
@@ -2305,7 +2305,7 @@ get_netdump_regs_x86_64(struct bt_info *
bt->machdep = (void *)user_regs;
}
-
+#endif
machdep->get_stack_frame(bt, ripp, rspp); }
Given the warning messages at the beginning of the process, I'm sure if
I'm dealing with a corrupted or incomplete vmcore image. Let me know
what additional info could be useful if this seems worth debugging
further.
Thanks,
-- Joe Lawrence
12 years, 9 months
[PATCH] do not check sp if ip points to user space
by Wen Congyang
If the task is a user program, the sp can be points to anywhere,
because we can modify sp in assembly.
For example:
.globl main
.type main, @function
main:
finit
subq $16, (%rsp)
movq $0, (%rsp)
.loop:
jmp .loop
12 years, 9 months
Accessing integer variables from sial
by Max Matveev
Dave, Luc,
This is the same patch I've sent to both of you back in January.
It applies cleanly against 5.1.8
I'd like to get it into the official tree - it does solve the problem
of getting access to integer variables from sial and so far I haven't
seen any side-effects.
max
12 years, 9 months
crash cannot read the symbols
by Koornstra, Reinoud
Hi Everyone,
I am just trying load a kernel and System.map file into crash.
crash vmlinux System.map
I get:
crash 5.1.7
Copyright (C) 2002-2011 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005 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.0
Copyright (C) 2009 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 "i686-pc-linux-gnu"...
crash: vmlinux: no debugging data available
However, the System.map file reads fine and "nm vmlinux" shows the symbols as well.
A side note that this is a linux 2.4 kernel.
Is linux 2.4 not supported or what am I doing wrong?
Thanks,
Reinoud.
12 years, 9 months
[PATCH] Fix warning: multiple active tasks have called die
by Michael Holzheu
Hi Dave,
When opening an s390(x) dump where the kernel has panic'ed, I currently
get the following warnings:
WARNING: multiple active tasks have called die and/or panic
WARNING: multiple active tasks have called die
In task.c we call "foreach bt -t" and check if we find "die" on the stack. When
doing this on s390 with the "-t" option normally we find multiple die() calls
for one single task:
crash> foreach bt -t | grep "die at"
[ 9ca7f7f0] die at 100f26
[ 9ca7f8f0] die at 100f26
[ 9ca7f9b8] die at 100f26
[ 9ca7fa40] die at 100ee6
[ 9ca7fa90] die at 100f26
The current code then assumes that multiple tasks have called die().
This patch fixes this problem by an additional check that allows multiple
occurrences of the die() call on the stack (with bt -t) for one task.
Signed-off-by: Michael Holzheu <holzheu(a)linux.vnet.ibm.com>
---
task.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
--- a/task.c
+++ b/task.c
@@ -5587,7 +5587,8 @@ panic_search(void)
dietask = lasttask;
break;
default:
- dietask = NO_TASK+1;
+ if (dietask != lasttask)
+ dietask = NO_TASK+1;
break;
}
}
@@ -6444,7 +6445,8 @@ clear_active_set(void)
die_task = task; \
break; \
default: \
- die_task = NO_TASK+1; \
+ if (die_task != task) \
+ die_task = NO_TASK+1; \
break; \
} \
} \
@@ -6457,7 +6459,8 @@ clear_active_set(void)
xendump_panic_hook(buf); \
break; \
default: \
- panic_task = NO_TASK+1; \
+ if (panic_task != task) \
+ panic_task = NO_TASK+1; \
break; \
} \
} \
12 years, 9 months
ARM panic registers
by Per Fransson
Hi Dave et. al.,
For ARM {k,net}dumps panic tasks we go to great lengths to locate
the prstatus data (crash registers) in
netdump.c:get_netdump_regs_arm()
In fact we rely so hard on them having been read from the CORE
ELF notes and put in either
nd->nt_prstatus_percpu
or
nd->nt_prstatus
that there's a segfault if that's not the case. The thing is,
once we've gone through all that trouble of finding them, and
making sure bt->machdep points to them,
arm.c:arm_get_stack_frame() is called, which ends up getting the
crash registers from
machdep->machspec->crash_task_regs
anyway. These are read directly from within the PT_LOAD segments
ignoring the contents any ELF notes.
I suggest changing get_netdump_regs_arm() to:
static void
get_netdump_regs_arm(struct bt_info *bt, ulong *eip, ulong *esp)
{
machdep->get_stack_frame(bt, eip, esp);
}
If we're not going to use the ELF notes, why fail if they're not
there?
Regards
Per
12 years, 9 months
[ANNOUNCE] crash version 5.1.8 is available
by Dave Anderson
Download from: http://people.redhat.com/anderson
Changelog:
- Fixes for gdb-7.0 ppc64/ppc-specific files to handle gcc-4.6 compiler
failures. Without the patch, gcc-4.6 generates "error: variable
‘<variable>’ set but not used [-Werror=unused-but-set-variable]"
fatal errors when the (default) -Werror flag is used. Previous gcc
versions considered local variables were simply set to some value to
be "used", but that is no longer the case.
(anderson(a)redhat.com)
- Add support for the "bt" command to recognize the new s390x
"restart_stack" used by the PSW restart interrupt in 3.0.1 and
later kernels.
(holzheu(a)linux.vnet.ibm.com)
- Enhancement to the s390x "bt" command to display the register
contents of the pt_regs strucutre for interrupts, instead of just
printing the string "- Interrupt -". The pt_regs structure contains
all of the current registers and PSW of the interrupted CPU.
(holzheu(a)linux.vnet.ibm.com)
- Removed the "files -l" option, which does not support 2.6 or later
kernels, and because it requires structure offset data that can only
be determined if the "lockd" and "nfsd" modules have been built into
the kernel. Given the kernel module dependencies, the command is
more suitable as an extension module, if anyone cares to carry on
its legacy.
(anderson(a)redhat.com)
- Fix for the "ps" command to disallow the mutually-exclusive "-u"
and "-k" options from being entered together. Without the patch,
whichever of the two options was entered last was acted upon.
Also, the help page was clarified by separating the three process
identifier formats from the "-u", "-k" and "-G" qualifiers.
(anderson(a)redhat.com)
- Fix for the "ps" command to disallow the mutually-exclusive "-a",
"-t", "-c", "-p", "-g", "-l" and "-r" options from being entered
together. Without the patch, whichever of the seven options that was
entered last was acted upon.
- Added new "struct -[xd]" and "union -[xd]" options, which override
the current default output format with hexadecimal or decimal format
for just the command instance. The "-o" member offset values and
the structure size value are also controlled by the new options.
Without the patch, it would require changing the default output
format with "hex" or "dec" prior to executing the "struct" or "union"
command.
(anderson(a)redhat.com)
- Fix for the "fuser" command, which may occasionally precede its
output with the message "WARNING: FILE_NRHASH has changed from 32"
on 2.6.19 and later kernels. The message is harmless.
(anderson(a)redhat.com)
- Exported new set_temporary_radix() and restore_current_radix()
functions, which are used to temporarily override the current
output radix setting.
(anderson(a)redhat.com)
- Fixes for ARM gdb-7.0/bfd/elf32-arm.c file to handle gcc-4.6 compiler
failures. Without the patch, gcc-4.6 generates "error: variable
‘<variable>’ set but not used [-Werror=unused-but-set-variable]"
fatal errors when the (default) -Werror flag is used. Previous gcc
versions considered local variables were simply set to some value to
be "used", but that is no longer the case.
(anderson(a)redhat.com)
- Cosmetic fix for command-failure "Usage" messages to prevent the
output from exceeding 80 columns.
(anderson(a)redhat.com)
- Implemented a new "struct -p" option which can be used to dereference
pointer members and display the target data. The option can be used
with the struct_name.member[,member] format, or if not, all pointers
in the structure will be dereferenced. If the member is a pointer,
the member's data type will be prepended to the member name when
displaying the target address; on the subsequent line(s) the target's
symbol name will be displayed in brackets if appropriate, and if
possible, the target data will be displayed. For example, currently
to display an mm_struct's "pgd" member:
crash> mm_struct.pgd ffff810022e7d080
pgd = 0xffff81000e3ac000
crash>
The -p option shows the data type of "pgd", dereferences the pointer
value, and with -x, displays the target's contents in hexadecimal
regardless of the current output format:
crash> mm_struct.pgd ffff810022e7d080 -px
pgd_t *pgd = 0xffff81000e3ac000
-> {
pgd = 0x2c0a6067
}
crash>
Here the "thread_info" and "binfmt" members of a task_struct
are dereferenced and the targets displayed:
crash> task_struct.thread_info,binfmt ffff8100181190c0 -p
struct thread_info *thread_info = 0xffff810023c06000
-> {
task = 0xffff8100181190c0,
exec_domain = 0xffffffff802f78e0,
flags = 128,
status = 1,
cpu = 3,
preempt_count = 0,
addr_limit = {
seg = 18446604435732824064
},
restart_block = {
fn = 0xffffffff80095a52 <do_no_restart_syscall>,
arg0 = 0,
arg1 = 0,
arg2 = 0,
arg3 = 0
}
}
struct linux_binfmt *binfmt = 0xffffffff80305540
-> <elf_format> {
next = 0xffffffff80305500,
module = 0x0,
load_binary = 0xffffffff80017d99 <load_elf_binary>,
load_shlib = 0xffffffff800838c3 <load_elf_library>,
core_dump = 0xffffffff80086465 <elf_core_dump>,
min_coredump = 4096
}
crash>
When a .member is not specified, all pointers in the structure
are dereferenced, which may be quite verbose depending upon
the structure.
(anderson(a)redhat.com)
- Implemented support for "SADUMP" dumpfiles, which are created by the
Fujitsu Stand Alone Dump facility. The dump-creation mechanism is
based in hardware-specific firmware, generating a dumpfile in three
different formats: sadump dump device (single partition), sadump dump
device (disk set), and archive file formats. The crash utility
recognizes all three formats.
(d.hatayama(a)jp.fujitsu.com)
- Fix for the "bt" command to display Control registers 8-15 (s390x and
s390) and floating point registers 8-15 (s390x only) correctly.
Without the patch, the register content was copied from the wrong
location of the save area, and the wrong register values were
displayed for the active tasks.
(holzheu(a)linux.vnet.ibm.com)
- Fix for 2.6.34 ppc64 kernels, which were changed to dynamically
allocate the paca structure, and changed the data type of "paca"
symbol from array to a paca_struct pointer.
(mahesh(a)linux.vnet.ibm.com)
- Fix for 2.6.36 and later ppc64 kernels, which overwrite the paca
pointer variable to point to a static paca during a crash sequence
just prior to the kexec of the secondary kernel, which contains a
paca_struct.data_offset value that is valid only for crashing cpu.
However, the kernel change also re-introduced the __per_cpu_offset
array, which had been removed in 2.6.15, which will be used as an
alternative to the per-cpu paca_struct.
(mahesh(a)linux.vnet.ibm.com)
- The new version of makedumpfile, 1.4.0, contains a facility that
allows a user to filter out kernel data (e.g., security keys,
confidential/secret information, etc.) from a vmcore. The data
that is filtered out is poisoned with character 'X' (0x58). A
filtered ELF kdump vmcore now contains a new "ERASEINFO" ELF note
section that contains the filter data strings used by makedumpfile.
A filtered compressed kdump has a header version number 5, and
contains new offset_eraseinfo and size_eraseinfo members in its
sub-header that point to a copy of the filter data strings. In most
cases, the erased kernel data will be inconsequential to the crash
session, but it is certainly possible that the removal of crucial
kernel data that the crash utility needs may cause the crash session
to fail, cause individual commands to fail, or result in other
unpredictable runtime behaviour. This patch detects whether kernel
data has been erased from the dumpfile, and if so, displays an early
warning message alerting the user. The "help -n" command displays
the filter data strings that were used by makedumpfile.
(mahesh(a)linux.vnet.ibm.com)
12 years, 9 months
[patch] crash: Show warning message if specified dumpfile has its kernel data scrubbed out.
by Mahesh J Salgaonkar
The new version of makedumpfile 1.4.0 allows user to filter out kernel data
(e.g. security keys, confidential/secret information etc.) from the vmcore.
The data to be filtered out is poisoned with character 'X' (0x58 in Hex).
The filtered ELF kdump now carries a new ELF note section "ERASEINFO" that
contains eraseinfo data. The filtered compressed kdump now contains new
members (offset_eraseinfo, size_eraseinfo) int the sub header with new header
version 5.
With the above change in place, there may be instances where the filtered
dumpfile may not be readable OR may not be helpful in analyzing the problem
using crash tool. Most of the time crash tool will be able to read/analyze
the dump unless someone scrubs out the data on which crash utility is
dependent on. Hence, This patch adds support into crash utility to detect the
above changes and show early warning message to the user about the fact that
he is dealing with filtered dumpfile.
This patch adds support for "help -n" output to display the filter data
strings that are appended to the dumpfile or stored in an ELF note.
Signed-off-by: Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com>
---
defs.h | 1 +
diskdump.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
diskdump.h | 2 ++
main.c | 5 +++++
netdump.c | 22 ++++++++++++++++------
5 files changed, 84 insertions(+), 6 deletions(-)
Index: crash-5.1.7/defs.h
===================================================================
--- crash-5.1.7.orig/defs.h
+++ crash-5.1.7/defs.h
@@ -431,6 +431,7 @@ struct program_context {
#define FLAT (0x1ULL)
#define ELF_NOTES (0x2ULL)
#define GET_OSRELEASE (0x4ULL)
+#define ERASEINFO_DATA (0x8ULL)
#define FLAT_FORMAT() (pc->flags2 & FLAT)
#define ELF_NOTES_VALID() (pc->flags2 & ELF_NOTES)
char *cleanup;
Index: crash-5.1.7/main.c
===================================================================
--- crash-5.1.7.orig/main.c
+++ crash-5.1.7/main.c
@@ -603,6 +603,11 @@ main(int argc, char **argv)
void
main_loop(void)
{
+ if (pc->flags2 & ERASEINFO_DATA)
+ error(WARNING, "\nFile %s may not be readable/analyzable. Some"
+ " of the kernel data from the dump has been scrubbed"
+ " out\n", pc->dumpfile);
+
if (!(pc->flags & GDB_INIT)) {
gdb_session_init();
show_untrusted_files();
Index: crash-5.1.7/netdump.c
===================================================================
--- crash-5.1.7.orig/netdump.c
+++ crash-5.1.7/netdump.c
@@ -1636,13 +1636,13 @@ dump_Elf32_Nhdr(Elf32_Off offset, int st
char buf[BUFSIZE];
char *ptr;
ulong *uptr;
- int xen_core, vmcoreinfo;
+ int xen_core, vmcoreinfo, eraseinfo;
uint64_t remaining, notesize;
note = (Elf32_Nhdr *)((char *)nd->elf32 + offset);
BZERO(buf, BUFSIZE);
- xen_core = vmcoreinfo = FALSE;
+ xen_core = vmcoreinfo = eraseinfo = FALSE;
ptr = (char *)note + sizeof(Elf32_Nhdr);
if (ptr > (nd->elf_header + nd->header_size)) {
@@ -1730,6 +1730,7 @@ dump_Elf32_Nhdr(Elf32_Off offset, int st
default:
xen_core = STRNEQ(buf, "XEN CORE") || STRNEQ(buf, "Xen");
vmcoreinfo = STRNEQ(buf, "VMCOREINFO");
+ eraseinfo = STRNEQ(buf, "ERASEINFO");
if (xen_core) {
netdump_print("(unknown Xen n_type)\n");
if (store)
@@ -1739,6 +1740,10 @@ dump_Elf32_Nhdr(Elf32_Off offset, int st
netdump_print("(unused)\n");
nd->vmcoreinfo = (char *)(ptr + note->n_namesz + 1);
nd->size_vmcoreinfo = note->n_descsz;
+ } else if (eraseinfo) {
+ netdump_print("(unused)\n");
+ if (note->n_descsz)
+ pc->flags2 |= ERASEINFO_DATA;
} else
netdump_print("(?)\n");
break;
@@ -1813,7 +1818,7 @@ dump_Elf32_Nhdr(Elf32_Off offset, int st
if (xen_core)
uptr = (ulong *)roundup((ulong)uptr, 4);
- if (vmcoreinfo) {
+ if (vmcoreinfo || eraseinfo) {
netdump_print(" ");
ptr += note->n_namesz + 1;
for (i = 0; i < note->n_descsz; i++, ptr++) {
@@ -1856,14 +1861,14 @@ dump_Elf64_Nhdr(Elf64_Off offset, int st
ulonglong *uptr;
int *iptr;
ulong *up;
- int xen_core, vmcoreinfo;
+ int xen_core, vmcoreinfo, eraseinfo;
uint64_t remaining, notesize;
note = (Elf64_Nhdr *)((char *)nd->elf64 + offset);
BZERO(buf, BUFSIZE);
ptr = (char *)note + sizeof(Elf64_Nhdr);
- xen_core = vmcoreinfo = FALSE;
+ xen_core = vmcoreinfo = eraseinfo = FALSE;
if (ptr > (nd->elf_header + nd->header_size)) {
error(WARNING,
@@ -1981,6 +1986,7 @@ dump_Elf64_Nhdr(Elf64_Off offset, int st
default:
xen_core = STRNEQ(buf, "XEN CORE") || STRNEQ(buf, "Xen");
vmcoreinfo = STRNEQ(buf, "VMCOREINFO");
+ eraseinfo = STRNEQ(buf, "ERASEINFO");
if (xen_core) {
netdump_print("(unknown Xen n_type)\n");
if (store)
@@ -1997,6 +2003,10 @@ dump_Elf64_Nhdr(Elf64_Off offset, int st
if (READ_PAGESIZE_FROM_VMCOREINFO() && store)
nd->page_size = (uint)
vmcoreinfo_read_integer("PAGESIZE", 0);
+ } else if (eraseinfo) {
+ netdump_print("(unused)\n");
+ if (note->n_descsz)
+ pc->flags2 |= ERASEINFO_DATA;
} else
netdump_print("(?)\n");
break;
@@ -2090,7 +2100,7 @@ dump_Elf64_Nhdr(Elf64_Off offset, int st
lf = 0;
netdump_print("%08lx ", *iptr++);
}
- } else if (vmcoreinfo) {
+ } else if (vmcoreinfo || eraseinfo) {
netdump_print(" ");
ptr += note->n_namesz + 1;
for (i = 0; i < note->n_descsz; i++, ptr++) {
Index: crash-5.1.7/diskdump.c
===================================================================
--- crash-5.1.7.orig/diskdump.c
+++ crash-5.1.7/diskdump.c
@@ -516,6 +516,12 @@ restart:
machdep->process_elf_notes(dd->notes_buf, size);
}
+ /* Check if dump file contains erasesinfo data */
+ if (KDUMP_CMPRS_VALID() && (dd->header->header_version >= 5) &&
+ (sub_header_kdump->offset_eraseinfo) &&
+ (sub_header_kdump->size_eraseinfo))
+ pc->flags2 |= ERASEINFO_DATA;
+
/* For split dumpfile */
if (KDUMP_CMPRS_VALID()) {
is_split = ((dd->header->header_version >= 2) &&
@@ -1016,6 +1022,50 @@ err:
}
static void
+dump_eraseinfo(FILE *fp)
+{
+ char *buf = NULL;
+ unsigned long i = 0;
+ unsigned long size_eraseinfo = dd->sub_header_kdump->size_eraseinfo;
+ off_t offset = dd->sub_header_kdump->offset_eraseinfo;
+ const off_t failed = (off_t)-1;
+
+ if ((buf = malloc(size_eraseinfo)) == NULL) {
+ error(FATAL, "compressed kdump: cannot malloc eraseinfo"
+ " buffer\n");
+ }
+
+ if (FLAT_FORMAT()) {
+ if (!read_flattened_format(dd->dfd, offset, buf, size_eraseinfo)) {
+ error(INFO, "compressed kdump: cannot read eraseinfo data\n");
+ goto err;
+ }
+ } else {
+ if (lseek(dd->dfd, offset, SEEK_SET) == failed) {
+ error(INFO, "compressed kdump: cannot lseek dump eraseinfo\n");
+ goto err;
+ }
+ if (read(dd->dfd, buf, size_eraseinfo) < size_eraseinfo) {
+ error(INFO, "compressed kdump: cannot read eraseinfo data\n");
+ goto err;
+ }
+ }
+
+ fprintf(fp, " ");
+ for (i = 0; i < size_eraseinfo; i++) {
+ fprintf(fp, "%c", buf[i]);
+ if (buf[i] == '\n')
+ fprintf(fp, " ");
+ }
+ if (buf[i - 1] != '\n')
+ fprintf(fp, "\n");
+err:
+ if (buf)
+ free(buf);
+ return;
+}
+
+static void
dump_nt_prstatus_offset(FILE *fp)
{
struct kdump_sub_header *sub_header_kdump = dd->sub_header_kdump;
@@ -1260,6 +1310,16 @@ __diskdump_memory_dump(FILE *fp)
}
dump_nt_prstatus_offset(fp);
}
+ if (dh->header_version >= 5) {
+ fprintf(fp, " offset_eraseinfo: %lx\n",
+ (ulong)dd->sub_header_kdump->offset_eraseinfo);
+ fprintf(fp, " size_eraseinfo: %lu\n",
+ dd->sub_header_kdump->size_eraseinfo);
+ if (dd->sub_header_kdump->offset_eraseinfo &&
+ dd->sub_header_kdump->size_eraseinfo) {
+ dump_eraseinfo(fp);
+ }
+ }
fprintf(fp, "\n");
} else
fprintf(fp, "(n/a)\n\n");
Index: crash-5.1.7/diskdump.h
===================================================================
--- crash-5.1.7.orig/diskdump.h
+++ crash-5.1.7/diskdump.h
@@ -67,6 +67,8 @@ struct kdump_sub_header {
unsigned long size_vmcoreinfo; /* header_version 3 and later */
off_t offset_note; /* header_version 4 and later */
unsigned long size_note; /* header_version 4 and later */
+ off_t offset_eraseinfo; /* header_version 5 and later */
+ unsigned long size_eraseinfo; /* header_version 5 and later */
};
/* page flags */
12 years, 9 months
