| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
Suppress the following warnings in get_elf64_phnum() on 32-bit system.
elf_info.c: In function 'get_elf64_phnum':
elf_info.c:1052: warning: format '%lx' expects type 'long unsigned int',
but argument 4 has type 'Elf64_Off'
elf_info.c:1057: warning: format '%lx' expects type 'long unsigned int',
but argument 4 has type 'Elf64_Off'
Signed-off-by: Kazuhito Hagio <k-hagio@ab.jp.nec.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In ELF dump mode, since makedumpfile cannot handle more than PN_XNUM
(0xFFFF) program headers, if a resulting dumpfile needs such a number
of program headers, it creates a broken ELF dumpfile like this:
# crash vmlinux dump.elf
...
WARNING: possibly corrupt Elf64_Nhdr: n_namesz: 4185522176 n_descsz: 3 n_type: f4000
...
WARNING: cannot read linux_banner string
crash: vmlinux and dump.elf do not match!
With this patch, if the actual number of program headers is PN_XNUM
or more, the e_phnum field of the ELF header is set to PN_XNUM, and
the actual number is set in the sh_info field of the section header
at index 0.
The section header is written just after the program headers, although
this order is not typical, for the sake of code simplisity.
Signed-off-by: Kazuhito Hagio <k-hagio@ab.jp.nec.com>
|
| |
|
|
|
|
|
|
|
|
| |
- x86_64: Add info->phys_base value
- Add VMCOREINFO data
- Change the output formats of PT_LOAD and mem_map to make them
shorter and more readable
- Remove some extra new lines
Signed-off-by: Kazuhito Hagio <k-hagio@ab.jp.nec.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently, conversion from physical address to virtual address in
--mem-usage option is "paddr + PAGE_OFFSET", which was written for
x86_64, but it's not suitable especially for arm64.
This patch introduces paddr_to_vaddr() macro to get prepared for
arch-specific physical to virtual conversion.
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
Signed-off-by: Kazuhito Hagio <k-hagio@ab.jp.nec.com>
|
| |
|
|
|
|
|
|
|
|
| |
With kaslr enabled, PAGE_OFFSET may no longer be aligned to allow
calculation using bitwise OR. My fix follows the same idea as
Baoquan's commit 4c53423b995463067fbbd394e724b4d1d6ea3d62 for
set_kcore_vmcoreinfo, i.e. use arithmetic addition instead.
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The crashed reserved memory end offset is the last address within
range, whereas the end offset in the pt_loads[] denotes the first
address past the range. This has caused a number of off-by-one
errors in exclude_segment().
First, let's unify the meaning of "end" to be the first out-of-range
address, i.e. start + size. Thanks to that, no +1 or -1 adjustments
are needed in exclude_segment().
Second, since the value read from /proc/iomem is the last address
within range, add one when passing it as an argument to
exclude_segment(). This is now the only adjustment by one.
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I received following on a specific x86_64 hp virtual machine while
executing `makedumpfile --mem-usage /proc/kcore`.
vtop4_x86_64: Can't get a valid pte.
readmem: Can't convert a virtual address(ffffffff88115860) to physical address.
readmem: type_addr: 0, addr:ffffffff88115860, size:128
get_nodes_online: Can't get the node online map.
With some debug print in vtop4_x86_64() I noticed that pte value is read
as 0, while crash reads the value correctly:
from makedumpfile:
vaddr=ffffffff88115860
page_dir=59eaff8
pml4=59ed067
pgd_paddr=59edff0
pgd_pte=59ee063
pmd_paddr=59ee200
pmd_pte=3642f063
pte_paddr=3642f8a8
pte=0
from crash
crash> vtop ffffffff88115860
VIRTUAL PHYSICAL
ffffffff88115860 5b15860
PML4 DIRECTORY: ffffffff87fea000
PAGE DIRECTORY: 59ed067
PUD: 59edff0 => 59ee063
PMD: 59ee200 => 3642f063
PTE: 3642f8a8 => 5b15163
PAGE: 5b15000
With some more debug prints in elf_info.c
Before calling exclude_segment()
LOAD (2)
phys_start : 100000
phys_end : dfffd000
virt_start : ffff8a5a40100000
virt_end : ffff8a5b1fffd000
file_offset: a5a40102000
file_size : dfefd000
exclude_segment() is called for Crash Kernel whose range is
2b000000-350fffff.
We see following after exclude_segment()
LOAD (2)
phys_start : 100000
phys_end : 2affffff
virt_start : ffff8a5a40100000
virt_end : ffff8a5a6affffff
file_offset: a5a40102000
file_size : dfefd000
LOAD (3)
phys_start : 35100000
phys_end : dfffd000
virt_start : ffff8a5a75100000
virt_end : ffff8a5b1fffd000
file_offset: a5a75102000
file_size : 0
Since file_size is calculated wrong therefore readpage_elf() does not
behave correctly.
This patch fixes above wrong behavior.
Signed-off-by: Pratyush Anand <panand@redhat.com>
|
| |
|
|
|
|
|
| |
commit f10d1e2e94c50 introduced another bug while fixing memory leak.
Use the braces with if condition.
Signed-off-by: Pratyush Anand <panand@redhat.com>
|
| |
|
|
|
|
|
| |
Fix memory leaks for error path in get_kcore_dump_loads().
This is not actual issue but bad manner.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
|
| |
|
|
|
|
|
|
|
|
| |
Kernel commit 464920104bf7 (/proc/kcore: update physical address for
kcore ram and text) provides physical address of direct mapping kcore
program segments. So no need to calculate it specifically now. And the
old code is not correct since it calls vaddr_to_paddr() which has not
been ready at that time.
Signed-off-by: Baoquan He <bhe@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
set_kcore_vmcoreinfo
In set_kcore_vmcoreinfo, we calculate the virtual address of vmcoreinfo
by OR operation as below:
kvaddr = (ulong)vmcoreinfo_addr | PAGE_OFFSET;
When mm sections kaslr is not enabled, this is correct since the
starting address of direct mapping section is 0xffff880000000000 which
is 1T aligned. Usually system with memory below 1T won't cause problem.
However with mm section kaslr enabled, the starting address of direct
mapping is 1G aligned. The above code makes kvaddr unsure.
So change it to adding operation:
kvaddr = (ulong)vmcoreinfo_addr + PAGE_OFFSET;
Signed-off-by: Baoquan He <bhe@redhat.com>
|
| |
|
|
|
|
|
|
|
|
| |
kcore passes correct phys_start for direct mapped region and an invalid
value (-1) for all other regions after the kernel commit
464920104bf7(/proc/kcore: update physical address for kcore ram and
text). arch specific function is_phys_addr() accepts only virt_start.
Therefore, check for valid phys_start in get_kcore_dump_loads().
Signed-off-by: Pratyush Anand <panand@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current code in readpage_elf (and readpage_elf_parallel) is extremely
hard to follow. Additionally, it still does not cover all possible cases.
For example, attempts to read outside of any ELF segment will end up with
phys_start being 0, frac_head a negative number, interpreted as a large
positive number by memset() and write past buffer end.
Instead of trying to handle even more "corner cases", I rewrote the
algorithm from scratch. The basic idea is simple: set a goal to fill the
page buffer with data, then work towards that goal by:
- filling holes with zeroes (see Note below),
- p_filesz portions with file data and
- remaining p_memsz portions again with zeroes.
Repeat this method for each LOAD until the goal is achieved, or an error
occurs. In most cases, the loop runs only once.
Note: A "hole" is data at a physical address that is not covered by any
ELF LOAD program header. In other words, the ELF file does not specify
any data for such a hole (not even zeroes). So, why does makedumpfile
fill them with zeroes? It's because makedumpfile works with page
granularity (the compressed format does not even have a way to store
a partial page), so if only part of a page is stored, a complete page
must be provided to make this partial data accessible.
Credits to Ivan Delalande <colona@arista.com> who first found the
problem and wrote the original fix.
Tested-by: Ivan Delalande <colona@arista.com>
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Pages that were filtered in the original dump file should also be filtered
in the destination file, i.e. pages between p_filesz and p_memsz must have
their corresponding bit cleared in the 2nd bitmap. Note that in theory,
such ELF segments might not refer to filtered pages, because the crash
kernel copies the program headers verbatim from elfcorehdr=. However, all
common sources of /proc/vmcore program headers use the same value for each
p_memsz and p_filesz:
a. kexec(8)
Program headers are created in two places, but in both cases the value
of p_memsz is equal to p_filesz.
Reference: kexec/crashdump-elf.c in kexec-tools
b. kexec_file_load(2)
Conceptually the same code as kexec(8): two places, both set p_filesz
and p_memsz to the same value.
Reference: kexec/crashdump-elf.c in Linux kernel
c. created in the crash kernel (s390)
On s390, program headers are created in the crash kernel, but both
p_filesz and p_memsz are set to "end - start", i.e. the same value.
Reference: arch/s390/kernel/crash_dump.c in Linux kernel
The above means that p_memsz > p_filesz only in ELF files that were
processed by makedumpfile, hence it can be safely assumed that pages
between p_filesz and p_memsz were filtered out.
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally, makedumpfile was designed to read from /proc/vmcore, where
each segment's p_memsz is equal to its p_filesz (see below). However,
makedumpfile can also be used to re-filter an already filtered ELF dump
file, where memory size may be larger than file size. In that case the
memory size should be used as the size of the segment. This affects:
1. max_mapnr
This value is computed as the highest phys_end. If the last segment
was filtered, max_mapnr may be too small, and the crash utility will
refuse to read that memory (even with --zero_excluded).
2. p_memsz field in ELF dumps
The resulting ELF segment p_memsz will be capped to original file's
p_filesz, ignoring the original p_memsz.
3. memory holes in KDUMP dumps
Pages excluded in the original ELF dump will be appear as memory
holes in the resulting KDUMP file's first bitmap.
4. vtop translation
Virtual addresses that were filtered out in the original ELF file
cannot be translated to physical addresses using the generic vtop
translation.
My fix uses p_memsz to set physical and virtual extents of ELF segments,
because this is their actual size. However, file size is important when
accessing page data, so it must be stored separately and checked when
translating a physical address to a file offset.
Signed-off-by: Petr Tesarik <ptesarik@suse.com>
|
| |
|
|
|
|
|
|
| |
Replace is_vmalloc_addr() by is_phys_addr() and implement is_phys_addr()
on s390x using /proc/iommem parsing to enable the new makedumpfile
option "--mem-usage".
Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
|
| |
|
|
|
|
|
|
|
|
| |
Move the following two functions from internal function to external
function.
get_elf64_phdr(int fd, char *filename, int index, Elf64_Phdr *phdr)
get_elf32_phdr(int fd, char *filename, int index, Elf32_Phdr *phdr)
Signed-of-by: Wang Xiao <wangx.fnst@cn.fujitsu.com>
|
| |
|
|
|
|
|
|
| |
In kcore, only "System Ram" and "kernel text" program segments
are needed. And to be more precise, exclude the crashkernel
memory range.
Signed-off-by: Baoquan He <bhe@redhat.com>
|
| |
|
|
|
|
|
|
|
| |
In vmcore dumping, note program of vmcoreinfo is set in elf header
of /proc/vmcore. In 1st kernel, the vmcoreinfo is also needed for
kcore analyzing. So in this patch information of vmcoreinfo is
parsed and set in offset_vmcoreinfo and size_vmcoreinfo.
Signed-off-by: Baoquan He <bhe@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add 2 preparation functions get_elf_loads and get_page_offset, later
they will be needed for parsing vmcoreinfo.
Meanwhile since get_kernel_version need be called to get page_offset
before initial() in mem_usage code flow, and surely it will be called
inside initial() again. Add a static variable to avoid this duplicate
calling.
Signed-off-by: Baoquan He <bhe@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now, we know that mmap() on /proc/vmcore for fractional pages
will fail due to a sanity check in remap_pfn_range().
In that case, current makedumpfile can fall back to read() mode,
but it's still desirable to use mmap() as much as possible for
performance.
This patch restricts the range of mmap() to avoid the fall back.
The original kernel issue was reported in:
https://lkml.org/lkml/2013/11/13/439
and it will be fixed in kernel 3.14.
Signed-off-by: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
get_pt_note_info() always ignores VMCOREINFO_XEN note because
buf size must be smaller than note size including \0 char.
Usualy this condition is true but when VMCOREINFO_XEN note
is encountered it does not work due to buf size defined
as sizeof("VMCOREINFO_XEN"). This patch fixes that bug
and VMCOREINFO_XEN note living in /proc/vmcore file
could be properly detected now.
v2 - suggestions/fixes:
- properly check buf size instead of increasing buf size
(suggested by Andrew Cooper).
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
|
| |
|
|
|
|
|
|
| |
Add the functions which convert a top address of a page to the
phys_{start|end} of the PT_LOAD entry correspond to the page
if the top address isn't covered by any PT_LOAD entries.
Signed-off-by: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
To see file offset of each memory chunk, it's correct to read
p_offset in the corresponing PT_LOAD entrie.
On /proc/vmcore PT_LOAD entries are sorted on p_load values in
increasing order. So, it's sufficient to refer to the last PT_LOAD
entry only. But the code here doesn't assuming that, calculating
maximum one from all the PT_LOAD entries.
Signed-off-by: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In ELF, the same integers for two note type represent different
meanings if the names they belong to are different. However,
get_pt_note_info() doesn't distinguish note types by name space, due
to which, for example, any new note type in "VMCOREINFO" name space is
wrongly interpretted as NT_PRSTATUS or the unique note type in
"VMCOREINFO" name space. This patch checks first ELF note names
explicitly and then ELF note types.
Signed-off-by: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently, get_pt_note_info() checks ELF note in "VMCOREINFO_XEN" name
first and then in "VMCOREINFO" name to avoid the case where
"VMCOREINFO_XEN" is wrongly interpreted as "VMCOREINFO". However,
characters checked by strncmp() includes null character. The case
concerned about there can never happen. This patch swaps checking
order of VMCOREINFO and VMCOREINFO_XEN, which is natural in the sense
that the direction from general one to specific one is natural.
Signed-off-by: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of seeking individual fields inside the ELF note, copy the
corresponding struct type from the Xen sources, so people can understand
why the code does what it does.
This is mainly a cleanup patch to improve maintainability, but it also
simplifies reusing the crash note data from other places.
Signed-off-by: Petr Tesarik <ptesarik@suse.cz>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Retrieve VMCOREINFO from VMLINUX and ELF note information from
VMCORE(s) and save them in generated DUMPFILE.
ELF note information is NT_PRSTATUS only. If crash_notes is NULL,
indicating kdump has not saved register values, save SMRAM CPU STATE
values. If crash_notes is not NULL, indicating kdump has saved
register values at crash, then save the register values in
crash_notes.
Signed-off-by: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Signed-off-by: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
|
| |
|
|
|
|
|
|
|
| |
A new n_type NT_ERASE_INFO(0xff) is not safe, because we cannot say
"It should not be duplicated to any other".
We can identify eraseinfo by ERASEINFO_NOTE_NAME without NT_ERASE_INFO,
and this patch does it.
Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
|
|
|
makedumpfile.c becomes big and the readability is not good.
To reduce the code of makedumpfile.c, this patch adds elf_info.c.
We need some other patches for the same purpose.
Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
|
