The '-n idle' option of bt command can help us filter the
stack of the idle process when debugging the dumpfiles
captured by kdump.
This patch supports this feature on ARM64.
Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
Crash reported an error on kernel v5.7 when live debugging with the
command "crash vmlinux /proc/kcore":
"crash: seek error: kernel virtual address: ffff75e9fffff000 type: "pud page""
The reason is that the PTOV() and arm64_vtop_4level_4k() do not work
as expected due to incorrect physvirt_offset.
To fix the above issue, need to read out the virtual address of
"physvirt_offset" from the "/proc/kallsyms", and update the
ms->phys_offset which is initialized with a wrong value in kernel
version [5.4, 5.10).
Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
The VMEMMAP_END did not exist before the kernel v5.7, but for now, the
value of vmemmap_end may be set to -1(0xffffffffffffffffUL).
According to the arch/arm64/mm/dump.c (before kernel v5.7):
..................................................
{ VMEMMAP_START + VMEMMAP_SIZE, "vmemmap end" }
..................................................
The vmemmap_end should always be:
vmemmap_end = vmemmap_vaddr + vmemmap_size;
This patch fixes the above issue.
Fixes: e397e1bef2 ("arm64: update the modules/vmalloc/vmemmap ranges")
Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
Since the kernel commit <2369f171d5c5> ("arm64: crash_core: Export
MODULES, VMALLOC, and VMEMMAP ranges"), crash can obtain the range
of module/vmalloc/vmemmap from the vmcore info, and no need to
calculate them manually.
This patch adds a new hook arm64_get_range_v5_18 which could parse
out all the module/vmalloc/vmemmap ranges from the vmcore info.
Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
Currently, the crash is implemented for arm64 based on kernel v4.20(and
earlier), and so far the kernel has evolved to v5.17-rc4. But the ranges
of MODULE/VMALLOC/VMEMMAP have not been updated since kernel v4.20.
Without the patch:
crash> help -m
...
vmalloc_start_addr: ffff800048000000
vmalloc_end: fffffdffbffeffff
modules_vaddr: ffff800040000000
modules_end: ffff800047ffffff
vmemmap_vaddr: fffffdffffe00000
vmemmap_end: ffffffffffffffff
...
With the patch:
crash> help -m
...
vmalloc_start_addr: ffff800010000000
vmalloc_end: fffffdffbffeffff
modules_vaddr: ffff800008000000
modules_end: ffff80000fffffff
vmemmap_vaddr: fffffdffffe00000
vmemmap_end: ffffffffffffffff
...
Link: https://listman.redhat.com/archives/crash-utility/2022-March/009625.html
Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
After kernel commit e2a073dde921 ("arm64: omit [_text, _stext) from
permanent kernel mapping"), the range [_text, _stext] is reclaimed. But
the current crash code still assumes kernel starting from "_text".
This change only affects the vmalloced area on arm64 and may result a
false in arm64_IS_VMALLOC_ADDR().
Since vmcore has no extra information about this trival change, it can
only be deduced from kernel version, which means ms->kimage_text can not
be correctly initialized until kernel_init() finishes. Here on arm64, it
can be done at the point machdep_init(POST_GDB). This is fine
since there is no access to vmalloced area at this stage.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
We can get VA_BITS_ACTUAL from CONFIG_ARM64_VA_BITS by guess.
Without this patch, we may need to use "--machdep vabits_actual=48" to
set the VA_BITS_ACTUAL.
Signed-off-by: Huang Shijie <shijie@os.amperecomputing.com>
Currently on arm64, NT_PRSTATUS notes in dumpfile are not mapped to
online cpus and machine_specific->panic_task_regs correctly. As a
result, the "bt" command can cause a segmentation fault.
crash> bt -c 0
PID: 0 TASK: ffff8000117fa240 CPU: 0 COMMAND: "swapper/0"
Segmentation fault (core dumped)
To fix this,
1) make map_cpus_to_prstatus_kdump_cmprs() map the notes to
dd->nt_prstatus_percpu also on arm64, and
2) move arm64_get_crash_notes() to machdep_init(POST_INIT) in order
to apply the mapping to machine_specific->panic_task_regs.
Resolves: https://github.com/crash-utility/crash/issues/105
Reported-by: xuchunmei000 <xuchunmei@linux.alibaba.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
Tested-by: David Wysochanski <dwysocha@redhat.com>
Update the default SECTION_SIZE_BITS value for arm64 Linux 5.12
and later kernels that contain kernel commit f0b13ee23241
("arm64/sparsemem: reduce SECTION_SIZE_BITS").
Reported-by: Ankur Bansal <er.ankurbansal@gmail.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
Commit 167d37e347 ("arm64: assign page_offset with VA_BITS kernel
configuration value") changed the page_offset calculation from
using VA_BITS_ACTUAL to CONFIG_ARM64_VA_BITS. This caused an error
for ramdumps without vmcoreinfo like this:
crash: vmlinux and /var/tmp/ramdump_elf_XUtCMT do not match!
Set the vmcoreinfo value to VA_BITS if available, and use VA_BITS
for page_offset calculation instead.
Also remove ARM64_FLIP_PAGE_OFFSET_ACTUAL because it's not used
actually.
Reported-by: Ankur Bansal <er.ankurbansal@gmail.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
Currently arm64 crash retrieves the CPU registers from crash_notes symbol
or ELF notes only when the symbol exists, but there are dumpfiles which
have the registers in ELF notes without the symbol.
With the patch, crash can retrieve the registers from ELF notes without
the crash_notes symbol.
Signed-off-by: James Hsu <james.hsu@mediatek.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
arm64 memory layout experiences big changes due to the following kernel
commits in date descending order:
5. 7bc1a0f9e176 arm64: mm: use single quantity to represent the PA to VA translation
4. b6d00d47e81a arm64: mm: Introduce 52-bit Kernel VAs
3. 5383cc6efed1 arm64: mm: Introduce vabits_actual
2. 14c127c957c1 arm64: mm: Flip kernel VA space
1. f80fb3a3d508 arm64: add support for kernel ASLR
For 1, crash has already used NEW_VMEMMAP to trace it.
For 2, crash lacks a flag to tag it and handle it differently.
For 3, two important kernel variables vabits_actual and physvirt_offset
are introduced.
For 4, since it comes immediately after 3, crash-utility does not need
to distinguish it.
For 5, kernel variable phyvirt_offset is removed
These changes have effects on PTOV()/VTOP() formula. So introducing
two bits HAS_PHYSVIRT_OFFSET and FLIPPED_VM as hint to apply different
formula.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
On RHEL9, crash hits a bug when executing "crash /proc/kcore":
seek error: kernel virtual address: ffff6a0f3fff0000 type: "pmd page"
The kernel virtual address does not vary with vabits_actual, instead,
is determined by configuration value. But crash does not observe this
fact.
Since vabits_actual related kernel commit is introduced after arm64
mm layout flip commit, so changes are safe under the condition if
(ms->VA_BITS_ACTUAL), and keep the else branch untouched.
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Reflect the flipped layout of kernel VA, which is introduced by
kernel commit 14c127c957c1 ("arm64: mm: Flip kernel VA space").
Signed-off-by: Pingfan Liu <piliu@redhat.com>
Commit 1c45cea "arm64: Change tcr_el1_t1sz variable name to
TCR_EL1_T1SZ", renamed the variable to upper case, but there are
kernels in existence that still have the lower case name, which
breaks crash backwards compatibility.
Resolves: https://github.com/crash-utility/crash/pull/82
Signed-off-by: John Donnelly <john.p.donnelly@oracle.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
With enough continuous physical memory we can have 1GB block.
This has been seen only in linear mapping region in kernel space.
Verified this for VM_L3_4K.
reference: alloc_init_pud(), use_1G_block() [arch/arm64/mm/mmu.c]
This problem can for instance be seen with vtop command, example:
crash> vtop ffffffd988008000
VIRTUAL PHYSICAL
ffffffd988008000 148008000
PAGE DIRECTORY: ffffff9188c6c000
PGD: ffffff9188c6cb30 => 68000140000711
PMD: ffffffd980000200 => aa0003e2b9402fe1
PAGE: 3e2b9400000 (2MB)
PTE PHYSICAL FLAGS
aa0003e2b9402fe1 3e2b9402000 (VALID|USER|RDONLY|SHARED|AF|NG)
Signed-off-by: Johan Erlandsson <johan.erlandsson@sony.com>
Update mapping symbol filter in arm64_verify_symbol() to support the
long form of mapping symbols, e.g. "$x.<any...>" described on [1].
Without the patch, the "dis" command cannot completely parse out the
disassembly of a function that has mapping symbols in the long form
and misses the tail part of the function.
[1] Morello Supplement to ELF for the Arm 64-bit Architecture
https://developer.arm.com/documentation/102072/
Signed-off-by: Qianli Zhao <zhaoqianli@xiaomi.com>
Signed-off-by: Kazuhito Hagio <k-hagio-ab@nec.com>
Since linux kernel commit bbdbc11804ff ("arm64/crash_core: Export
TCR_EL1.T1SZ in vmcoreinfo") [available in linux-next now], the name
of tcr_el1_t1sz vmcoreinfo variable has been changed to TCR_EL1_T1SZ.
Make a similar change in crash-utility.
Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
(1) Linux kernel patch "arm64: mm: Introduce vabits_actual"
introduced "physvirt_offset", which is not equal to
(PHYS_OFFSET - PAGE_OFFSET) when KASLR is enabled.
physvirt_offset is caculated in arch/arm64/mm/init.c
before memstart_addr (PHYS_OFFSET) is randomized. Let
arm64_VTOP() and arm64_PTOV() use physvirt_offset instead,
whose default value is set to (phys_offset - page_offset)
(2) For ARM64 RAM dumps without any vmcoreinfo and KASLRpassed as
argument, " _stext_vmlinux" is not set. This causes incorrect
calculation of vmalloc_start with VA_BITS_ACTUAL.
(3) For ARM64 RAM dumps For ramdumps without vmcoreinfo, get
CONFIG_ARM64_VA_BITS from in-kernel config. Without this,
vmemmap size is calculated incorrectly.
(4) Fix the vmemmap_start to match with what the kernel uses.
(vinayakm.list@gmail.com)
as in-kernel feature. The value of CONFIG_ARM64_KERNELPACMASK
will be exported as a vmcoreinfo entry, and will be used with text
return addresses on the kernel stack.
(amit.kachhap@arm.com)
line option for Linux 5.4 and later dumpfiles, which require the
kernel's dynamically-determined "vabits_actual" value for virtual
address translation. Without the patch, the crash session fails
during initialization with the error message "crash: cannot determine
VA_BITS_ACTUAL". This option will become unnecessary when the
proposed TCR_EL1.T1SZ vmcoreinfo entry entry is incorporated into
the kernel.
(anderson@redhat.com)
the virtual memory region between the end of the vmalloc region and
the beginning of the vmemmap region. Without the patch, reads of
virtual addresses within that region are not recognized properly
and will fail.
(zhaoqianli@xiaomi.com)
that contain commit b6e43c0e3129ffe87e65c85f20fcbdf0eb86fba0, titled
"arm64: remove __exception annotations". Without the patch, the
ARM64 crash session fails during initialization with the error
message "crash: cannot resolve __exception_text_start".
(anderson@redhat.com)
the new TCR_EL1.T1SZ vmcoreinfo entry, display its value during
session initialization only when invoking crash with "-d1" or larger
-d debug value.
(anderson@redhat.com)
read the per-cpu NT_PRSTATUS note contents if an invalid note is
encountered. Without the patch, if an invalid note is found, all
other notes were ignored, and subsequent "bt" attempts on the active
tasks would fail.
(chenqiwu@xiaomi.com, anderson@redhat.com)
ARM64 kernel SECTION_SIZE_BITS by reading the in-kernel configuration
data if there is no VMCOREINFO data available. In that case, without
the patch, a double-free exception may occur.
(anderson@redhat.com)
earlier kernels that do not have vmcoreinfo data. Without the patch,
the crash session fails during initialization with the error message
"crash: "cannot determine page size".
(chenqiwu@xiaomi.com)
order of precedence:
(1) from the VMCOREINFO data if it exists
(2) from the in-kernel configuration data if it exists
(3) the default value
(chenqiwu@xiaomi.com)
fa2a8445b1d3810c52f2a6b3a006456bd1aacb7e, titled "arm64: allow ID map
to be extended to 52 bits", and which have been configured with both
CONFIG_DEVMEM=y and CONFIG_STRICT_DEVMEM=y. Without the patch, an
inconsequential error message indicating "crash: read error: kernel
virtual address: <address> type: idmap_ptrs_per_pgd" is displayed
during initialization.
(anderson@redhat.com)
in Linux 4.6 and later kernels if an ELF format dumpfile:
(1) does not contain its value in a VMCOREINFO note, and
(2) if the kernel image was loaded at a higher address than the
system's physical base address.
This may happen, for example, when analyzing a dynamically-created
ramdump-to-ELF dumpfile.
(zhaoqianli@xiaomi.com, anderson@redhat.com)
architecture-specific value in the ELF header; its initial use
is for support of the upcoming ARM64 52-bit kernel virtual
address space by passing both the VA_BITS and VA_BITS_ACTUAL
values.
(anderson@redhat.com)
CONFIG_ARM64_PA_BITS=52
CONFIG_ARM64_64K_PAGES
CONFIG_PGTABLE_LEVELS=3
and that run on a host containing physical memory that utilizes
any bit in the uppermost 4 bits of the 52-bit physical address
range.
(anderson@redhat.com)
changes to support 52-bit kernel virtual addressing, which allows
the configuration of CONFIG_ARM64_VA_BITS to be 52, but where the
actual number of VA bits may be downgraded during boot depending
upon the hardware capability. This phase is only applicable for
live system analysis.
(anderson@redhat.com)
in kernel commit 982aa7c5f0861bf56b2412ca341a13f44c238ba4, titled
"arm64: add kconfig symbol to configure physical address size".
Without the patch, it is impossible to determine the value of
CONFIG_ARM64_PA_BITS, and will require a new MAX_PHYSMEM_BITS
vmcoreinfo entry to be exported. This patch reads that entry
during intitialization.
(anderson@redhat.com)
CONFIG_ARM64_USER_VA_BITS_52, which causes the PTRS_PER_PGD count
to increase from 64 to 1024. Without the patch, "WARNING: cannot
access vmalloc'd module memory" will be displayed during session
initialization, and the translation of any mapped kernel virtual
address that requires a page table walk will fail, leading to a
myriad of other errors.
(anderson@redhat.com)
header of /proc/kcore in Linux 4.19 and later kernels. This patch
introduces support for live session /proc/kcore VMCOREINFO access by
the crash utility's internal pc->read_vmcoreinfo() function. New
usage include the initialization of the x86_64 phys_base value, and
the arm64 phys_offset, page size, and VA bits count.
(anderson@redhat.com)
configured with CONFIG_RANDOMIZE_BASE. Without the patch, depending
upon the hardware platform, the session may fail with the error message
"crash: vmlinux and /proc/kcore do not match!".
(anderson@redhat.com)
running live against /proc/kcore. Without the patch, the message
"WARNING: cannot access vmalloc'd module memory" may be displayed
during session initialization, and vmalloc/module memory will be
unaccessible. It should be noted that at the time of this patch,
the upstream (4.16.0) version of /proc/kcore does not work correctly
for ARM64, because PT_LOAD segments for unity-mapped blocks of
physical memory are not generated.
(anderson@redhat.com)
fail during session initialization with the error message
"crash: cannot determine page size". The failure to determine
the page size is due to the combination of the following kernel
commits:
- Linux 4.6 commit 6ad1fe5d9077a1ab40bf74b61994d2e770b00b14
arm64: avoid R_AARCH64_ABS64 relocations for Image header fields
- Linux 4.10 commit 4b65a5db362783ab4b04ca1c1d2ad70ed9b0ba2a
arm64: Introduce uaccess_{disable,enable} functionality based on TTBR0_EL1
- Linux 4.16 commit 1e1b8c04fa3451e2b7190930adae43c95f0fae31
arm64: entry: Move the trampoline to be before PAN
(takahiro.akashi@linaro.org)
30d88c0e3ace625a92eead9ca0ad94093a8f59fe, titled "arm64: entry:
Apply BP hardening for suspicious interrupts from EL0". Without
the patch, there may be invalid kernel kernel exception frames
displayed on an active task's kernel stack, often below a stackframe
of the "do_el0_ia_bp_hardening" function; the address translation
of the PC and LR values in the the bogus exception frame will
display "[unknown or invalid address]".
(anderson@redhat.com)
later kernels. Without the patch, the backtraces of the active
tasks in a kdump-generated dumpfile are truncated. Without the
patch, the panic task will just show the "crash_kexec" frame
and the kernel-entry user-space exception frame; the non-panic
tasks will show their backtraces starting from the stackframe
addresses captured in the per-cpu NT_PRSTATUS notes, and will
not display the exception frame generated by the NMI callback,
nor any stackframes on the IRQ stack.
(anderson@redhat.com)
The patch corrects the contents of in-kernel exception frame register
dumps, and properly transitions the backtrace from the IRQ stack
to the process stack.
(takahiro.akashi@linaro.org)
Without the patch, a message indicating "crash: builtin stackframe.sp
offset incorrect!" is issued during session initialization, and the
"bt" command fails with the error message "bt: invalid structure
member offset: task_struct_thread_context_sp".
(anderson@redhat.com)
frame at the top of the stack in Linux 4.7 and later kernels.
Without the patch, the contents of the user mode exception frame are
invalid due to the miscalculation of the starting address of the
pt_regs structure on the kernel stack.
(anderson@redhat.com)
