Create a separate C header for FUSE to separate independent things and
make it more readable.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Create a separate C header for DFI VMCOREINFO to separate
independent things and make it more readable.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Replace magic values with descriptive names to improve readability.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
To prevent segmentation faults when the function dfi_mem_phys_read() is
given invalid parameters, check that the given memory range falls within
a known physical memory chunk, just like it is done for dfi_mem_virt_read().
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The new name describes the purpose of the function better and
emphasizes its difference with the function dfi_mem_phys_read().
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Always use the function dfi_mem_read_rc() which verifies that the given
address and size fall within a valid memory chunk. We cannot trust
user's input.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The function dfi_mem_chunk_virt_add() is used only internally and should
not be exported to prevent misuse.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The keyword extern is redundant for function declarations in C headers.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
zgetdump is for analyzing VM coredumps and not user space coredumps therefore
return an error in case of a user space coredump.
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This fixes the following Valgrind finding:
==28040== Syscall param rt_sigaction(act->sa_flags) points to uninitialised byte(s)
==28040== at 0x48C98B0: __libc_sigaction (sigaction.c:58)
==28040== by 0x10D507: sig_handler_init (zgetdump.c:58)
==28040== by 0x10D507: main (zgetdump.c:179)
==28040== Address 0x1ffefffc84 is on thread 1's stack
==28040== in frame #0, created by __libc_sigaction (sigaction.c:43)
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Sanity check ELF notes descriptor size before reading it. This prevents
stack buffer overflows in case a dump contains invalid ELF notes.
Instead of reading a note's descriptor into a temporary buffer on stack,
read it directly into the buffer given to nt_read() but also provide
a maximum length of the given buffer to nt_read() in order to prevent
overflows.
This problem was found with valgrind and AFL fuzzing + ASAN.
AFL + ASAN findings:
[root@t83lp49 s390-tools]# ./zdump/zgetdump -iVVVVV ~/zgetdump-fuzzing/findings/crashes/id\:000008\,sig\:06\,src\:000007\,op\:arith8\,pos\:67\,val\:+3
TRACE: DFI initialization
DEBUG: DFI trying s390tape
DEBUG: DFI s390tape returned with rc -19
DEBUG: DFI trying devmem
DEBUG: DFI devmem returned with rc -19
DEBUG: DFI trying s390mv_ext
DEBUG: DFI s390mv_ext returned with rc -19
DEBUG: DFI trying s390mv
DEBUG: DFI s390mv returned with rc -19
DEBUG: DFI trying s390_ext
DEBUG: DFI S390 extended initialization
DEBUG: DFI s390_ext returned with rc -19
DEBUG: DFI trying s390
DEBUG: DFI S390 initialization
DEBUG: DFI s390 returned with rc -19
DEBUG: DFI trying lkcd
DEBUG: DFI lkcd returned with rc -19
DEBUG: DFI trying elf
DEBUG: DFI ELF initialization
DEBUG: DFI ELF e_phnum 11
DEBUG: DFI ELF p_type[0] 0x4
DEBUG: DFI ELF n_type 0x0
AddressSanitizer:DEADLYSIGNAL
=================================================================
==208548==ERROR: AddressSanitizer: stack-overflow on address 0x03ffef05d000 (pc 0x0000010051b0 bp 0x03fff107dc40 sp 0x03ffef05dac8 T0)
#0 0x10051b0 (/root/s390-tools/zdump/zgetdump+0x10051b0)
SUMMARY: AddressSanitizer: stack-overflow (/root/s390-tools/zdump/zgetdump+0x10051b0)
==208548==ABORTING
valgrind findings:
==56423== Source and destination overlap in memcpy(0x4a86d38, 0x4a875e0, 4096)
==56423== at 0x4839F86: memcpy (in /usr/lib/s390x-linux-gnu/valgrind/vgpreload_memcheck-s390x-linux.so)
==56423== by 0x114253: memcpy (string_fortified.h:34)
==56423== by 0x114253: nt_read (dfi_elf.c:95)
==56423== by 0x1145FF: nt_s390_prefix_read (dfi_elf.c:195)
==56423== by 0x1145FF: pt_notes_add (dfi_elf.c:259)
==56423== by 0x1145FF: dfi_elf_init (dfi_elf.c:326)
==56423== by 0x112A57: dfi_init (dfi.c:1212)
==56423== by 0x10D663: do_dump_info (zgetdump.c:127)
==56423== by 0x10D663: main (zgetdump.c:182)
==56423==
==56423== Invalid write of size 8
==56423== at 0x4839E28: memcpy (in /usr/lib/s390x-linux-gnu/valgrind/vgpreload_memcheck-s390x-linux.so)
==56423== by 0x114253: memcpy (string_fortified.h:34)
==56423== by 0x114253: nt_read (dfi_elf.c:95)
==56423== by 0x1145FF: nt_s390_prefix_read (dfi_elf.c:195)
==56423== by 0x1145FF: pt_notes_add (dfi_elf.c:259)
==56423== by 0x1145FF: dfi_elf_init (dfi_elf.c:326)
==56423== by 0x112A57: dfi_init (dfi.c:1212)
==56423== by 0x10D663: do_dump_info (zgetdump.c:127)
==56423== by 0x10D663: main (zgetdump.c:182)
==56423== Address 0x4a86ee0 is 0 bytes after a block of size 912 alloc'd
==56423== at 0x483675E: calloc (in /usr/lib/s390x-linux-gnu/valgrind/vgpreload_memcheck-s390x-linux.so)
==56423== by 0x10E71D: zg_alloc (zg.c:93)
==56423== by 0x114793: nt_prstatus_read (dfi_elf.c:123)
==56423== by 0x114793: pt_notes_add (dfi_elf.c:234)
==56423== by 0x114793: dfi_elf_init (dfi_elf.c:326)
==56423== by 0x112A57: dfi_init (dfi.c:1212)
==56423== by 0x10D663: do_dump_info (zgetdump.c:127)
==56423== by 0x10D663: main (zgetdump.c:182)
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Suggested-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reported-by: Steffen Eiden <seiden@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
If the while loop in mem_chunks_add_ext() is never executed, then
the stack variable containing the dump segment header will never be
initialized.
clang's static code analyzer reports the following problem:
$ make CC="clang --analyze" -C zdump
dfi_s390.c:157:6: warning: Branch condition evaluates to a garbage value [core.uninitialized.Branch]
if (!dump_segm.stop_marker)
^~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Use util_log from libutil to output various log messages that can be helpful
during problem analysis.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Replace the incorrect %d format specifier with %u one for unsigned integer
types.
This issue was found with AFL fuzzing.
$ ./zdump/zgetdump -i ~/input.bin
General dump info:
Dump format........: s390
Version............: -2147483647
System arch........: s390x (64 bit)
CPU count (online).: 32768
Dump memory range..: 1 MB
Memory map:
0000000000000000 - 00000000000f423f (1 MB)
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Before reading data in dfi_vmcoreinfo_init(), check the validity
of the memory range. Otherwise this can result in a segmentation fault when
zgetdump is given a very small dump, e.g. S390 DASD single-volume dump of
size 0x10 bytes.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Before reading data in os_info_get(), check the validity of the memory
range. Otherwise this can result in a segmentation fault when zgetdump is
given a very small dump, e.g. S390 DASD single-volume dump of size 0x10
bytes.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Before reading data at addresses 0x10418 and 0x10420 in kdump_init(),
validate the validity of the memory range. Otherwise this can result in
a segmentation fault when zgetdump is given a very small dump, e.g.
S390 DASD single-volume dump of size 0x1000 bytes.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The dfi_vmcoreinfo_init() function might be called on a dump of a non-ELF
format because the DFI goes through all supported dump formats when first
trying to identify of what dump format the given input is. Therefore,
we must be very careful in interpreting read data and ensure that it
makes sense before accessing or using it.
This commit prevents a potential overflow of a stack buffer in
dfi_vmcoreinfo_init() if note.n_namesz is bigger than the stack buffer.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The function mem_chunks_add_ext() allocates but does not release memory
if it encounters unexpected errors during dump segment reading.
Allocate memory passed to dfi_mem_chunk_add() right before calling
the function. This way there is no need for a cleanup anymore.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
According to the ELF specification, the file size of a PT_LOAD
memory segment might be less than its memory size. In that case,
the remaining bytes must be filled with zeros. The ELF DFI implementation
didn't handle this case correctly. Such ELF core files might be produced
by the makedumpfile tool.
From elf.5 man page:
------------------------------------------------------
PT_LOAD
The array element specifies a loadable segment,
described by p_filesz and p_memsz. The bytes
from the file are mapped to the beginning of the
memory segment. If the segment's memory size
p_memsz is larger than the file size p_filesz,
the "extra" bytes are defined to hold the value
0 and to follow the segment's initialized area.
The file size may not be larger than the memory
size. Loadable segment entries in the program
header table appear in ascending order, sorted
on the p_vaddr member.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Before attempting to read ELF program headers, the file must be positioned
at the offset of the first program header as specified in the ELF header.
Furthermore, read all ELF program headers with one call to zg_read(). This
has the advantage of not having to restore the file offset every time
after it is changed in pt_notes_add() and other functions which need to
read the same file as well.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
This is a false positive because IBM Z architecture supports unaligned
memory accesses.
dfo_s390.c: In function ‘df_s390_dump_init’:
dfo_s390.c:218:29: warning: taking address of packed member of ‘struct df_s390_hdr’ may result in an unaligned pointer value [-Waddress-of-packed-member]
218 | timeval2tod(&dh->tod, dfi_attr_time());
| ^~~~~~~~
dfo_s390.c:219:29: warning: taking address of packed member of ‘struct df_s390_em’ may result in an unaligned pointer value [-Waddress-of-packed-member]
219 | timeval2tod(&em->tod, dfi_attr_time());
| ^~~~~~~~
dfo_s390.c:222:29: warning: taking address of packed member of ‘struct df_s390_em’ may result in an unaligned pointer value [-Waddress-of-packed-member]
222 | timeval2tod(&em->tod, dfi_attr_time_end());
| ^~~~~~~~
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
The DFI memory chunk manager cannot handle PT_LOAD segments of size 0.
This can lead to a NULL pointer access in mem_chunk_find() in case
zgetdump is given an invalid VMCORE ELF file as input which contains
only zero-sized ELF PT_LOAD segments. Instead of crashing, show an error
message and terminate gracefully.
The TELA test dump_with_zero_sized_segments.sh can reproduce this bug.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
If a memory chunk is added to mem_phys as well as mem_virt
in dfi_mem_chunk_add_vol() then an illegal memory access might occur
when accessing mem_chunk->data e.g. in dfi_elf_mem_chunk_read_fn()
because the data block pointed to by the data field is now being referenced
by two memory chunks, one in mem_phys and one in mem_virt. If it happens
that the memory chunk from mem_virt is freed in mem_unmap() then
the memory chunk in mem_phys still points to the common data block
which has been already freed. This leads to all sort of bad behavior
in dfi_elf_mem_chunk_read_fn() and other places where mem_chunk->data
might be accessed.
Fixes the following bug:
zgetdump: Unexpected end of file for "dump.all.elf"
And this was found by AddressSanitizer:
=================================================================
==81170==ERROR: AddressSanitizer: heap-use-after-free on address 0x602000000570 at pc 0x00000101ac10 bp 0x03ffd897e250 sp 0x03ffd897e248
READ of size 8 at 0x602000000570 thread T0
#0 0x101ac0f in dfi_elf_mem_chunk_read_fn s390-tools/zdump/dfi_elf.c:27
#1 0x100d8a5 in mem_read s390-tools/zdump/dfi.c:339
#2 0x100d8a5 in dfi_mem_phys_read s390-tools/zdump/dfi.c:616
#3 0x100d8a5 in mem_chunk_map_read_fn s390-tools/zdump/dfi.c:353
#4 0x100fd29 in mem_read s390-tools/zdump/dfi.c:339
#5 0x100fd29 in dfi_mem_read s390-tools/zdump/dfi.c:608
#6 0x1018e89 in os_info_get s390-tools/zdump/dfi_vmcoreinfo.c:65
#7 0x1018e89 in dfi_vmcoreinfo_init s390-tools/zdump/dfi_vmcoreinfo.c:86
#8 0x10175b3 in dfi_init s390-tools/zdump/dfi.c:1215
#9 0x1006e71 in do_stdout s390-tools/zdump/zgetdump.c:161
#10 0x1006e71 in main s390-tools/zdump/zgetdump.c:180
#11 0x3ffb07abb89 in __libc_start_main (/lib64/libc.so.6+0x2bb89)
#12 0x1007e8d (s390-tools/zdump/zgetdump+0x1007e8d)
0x602000000570 is located 0 bytes inside of 8-byte region [0x602000000570,0x602000000578)
freed by thread T0 here:
#0 0x3ffb0bc961b in free (/lib64/libasan.so.6+0xc961b)
#1 0x100d2d9 in mem_unmap s390-tools/zdump/dfi.c:1050
previously allocated by thread T0 here:
#0 0x3ffb0bc9aa9 in calloc (/lib64/libasan.so.6+0xc9aa9)
#1 0x100a271 in zg_alloc s390-tools/zdump/zg.c:93
SUMMARY: AddressSanitizer: heap-use-after-free s390-tools/zdump/dfi_elf.c:27 in dfi_elf_mem_chunk_read_fn
Shadow bytes around the buggy address:
0x100c0400000050: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
0x100c0400000060: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
0x100c0400000070: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
0x100c0400000080: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
0x100c0400000090: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
=>0x100c04000000a0: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa[fd]fa
0x100c04000000b0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa fd fa
0x100c04000000c0: fa fa fd fa fa fa fd fa fa fa fd fa fa fa 04 fa
0x100c04000000d0: fa fa 00 fa fa fa 00 fa fa fa 00 fa fa fa 00 fa
0x100c04000000e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x100c04000000f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==81170==ABORTING
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Verify the given ELF header before adding any memory chunks otherwise
a memory chunk might be added even if the given ELF header is invalid.
Signed-off-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When using zgetdump on a multi-volume device dump, the sysfs path to
determine the device node is incomplete, resulting in the following
error:
$ zgetdump -i /dev/dasdb1
zgetdump: Could not open "/sys/bus/ccw/devices/0.0.9300/dasdb/dev" (No
such file or directory)
A simple fix would be to add the missing "block" part in the sysfs path.
However, the logic still assumes sysfs links like "block:" that have
been deprecated a decade ago and are no longer present on modern
systems anyway.
Therefore, the logic can greatly be improved. Create a separate function
to determine whether a device is online, remove the logic for "block:"
entries, and use libutil functions to reduce the complexity even further.
Fixes: 70a79fab3c ("zgetdump: Avoid using PATH_MAX")
Reviewed-by: Alexander Egorenkov <egorenar@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Consolidate `ALIGN, __ALIGN_MASK, ARRAY_SIZE` macros and add them to
lib/zt_common.h. While at it, adapt coding style.
Reviewed-by: Philipp Rudo <prudo@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
We can safely replace strncpy() with memcpy() here and get rid of the
following compile warnings:
dfi_s390mv.c: In function ‘set_magic_numbers’:
dfi_s390mv.c:570:3: warning: ‘strncpy’ output truncated before
terminating nul copying 7 bytes fr om a string of the same length
[-Wstringop-truncation]
strncpy(l.dumper_magic, DF_S390_DUMPER_MAGIC_MV_EXT, 7);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dfi_s390mv.c:573:3: warning: ‘strncpy’ output truncated before
terminating nul copying 7 bytes fr om a string of the same length
[-Wstringop-truncation]
strncpy(l.dumper_magic, DF_S390_DUMPER_MAGIC_MV, 7);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Using inappropriate sizes for snprintf() leads to the following compile
warnings:
dfi_s390mv.c: In function ‘dev_from_busid’:
dfi_s390mv.c:116:34: warning: ‘/online’ directive output may be
truncated writing 7 bytes into a region of size between 1 and 4096
[-Wformat-truncation=]
snprintf(tmp_file, PATH_MAX, "%s/online", dev_file);
^~~~~~~
dfi_s390mv.c:116:2: note: ‘snprintf’ output between 8 and 4103 bytes
into a destination of size 4096
snprintf(tmp_file, PATH_MAX, "%s/online", dev_file);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dfi_s390mv.c:143:35: warning: ‘%s’ directive output may be truncated
writing up to 255 bytes into a region of size between 0 and 4095
[-Wformat-truncation=]
snprintf(tmp_file, PATH_MAX, "%s/%s/dev", dev_file, direntp->d_name);
^~
dfi_s390mv.c:143:2: note: ‘snprintf’ output between 6 and 4356 bytes
into a destination of size 4096
snprintf(tmp_file, PATH_MAX, "%s/%s/dev", dev_file, direntp->d_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A simple fix would be to use different suitable fixed sizes for tmp_file
and dev_file. However, the code can be improved here a little.
Use the libutil function util_path_sysfs() to build the sysfs path
string. This is more robust, as the function will figure out the correct
mount point of the sysfs. util_path_sysfs() will also terminate
execution, if no sysfs mount point could be found. That means, we can
get rid of check_sysfs().
Furthermore, the two variables (tmp_file, dev_file) can be combined to
one. Also, check the return value of open() and act accordingly.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add 'Dump file size' field for zgetdump -i output to show the actual size
of dump file in s390 extended format on disk in megabytes.
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Add verbose option for zgetdump to display the detailed layout of memory
map when printing dump info for s390_ext or ELF dump format.
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Adjust ELF formatted dump processing by zgetdump tool in order to handle
so-called zero loads using zero memory chunks introduced with s390
extended dump format.
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Update zgetdump tool to process dumps of the new s390 extended format.
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Update 'zgetdump -d' to process the new DASD dump tool installed (single
volume or multi-volume).
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Update df_s390_dumper structure and dumper reading functions to read
certain dumper fields instead of the entire dump tool.
Update other s390 dump common functions in preparation for the new dumper
and the new s390 extended dump format.
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
When dump is not complete or dump memory limit is set, zgetdump might end up
with the Segfault on reading Vector Registers. That might take place when
the Vector Registers save area is beyond the dump memory limit.
Signed-off-by: Mikhail Zaslonko <zaslonko@linux.vnet.ibm.com>
Reviewed-by: Philipp Rudo <prudo@linux.vnet.ibm.com>
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
