[PATCH v5 00/14] gdb stack unwinding support for crash utility
by Tao Liu
This patchset is a rebase/merged version of the following 3 patchsets:
1): [PATCH v10 0/5] Improve stack unwind on ppc64 [1]
2): [PATCH 0/5] x86_64 gdb stack unwinding support [2]
3): Clean up on top of one-thread-v2 [3]
A complete description of gdb stack unwinding support for crash can be
found in [1].
This patchset can be divided into the following 2 parts:
1) part1: arch independent, mainly modify on the
crash_target.c/gdb_interface.c files, in preparation of the
gdb side.
2) part2: arch specific part, for implementing ppc64/x86_64/arm64/vmware
gdb stack unwinding support.
=== part 2
- arm64:
arm64: Add gdb stack unwinding support
- vmware:
vmware_guestdump: Various format versions support
set_context(): check if context is already current
- x86_64:
x86_64: Fix invalid input "=>" for bt command
Fix cpumask_t recursive dependence issue
x86_64: Add gdb stack unwinding support
- ppc64:
ppc64: correct gdb passthroughs by implementing machdep->get_cpu_reg
=== part 1
Stop stack unwinding at non-kernel address
Fix gdb_interface: restore gdb's output streams at end of gdb_interface
Print task pid/command instead of CPU index
Rename get_cpu_reg to get_current_task_reg
Let crash change gdb context
Leave only one gdb thread for crash
Remove 'frame' from prohibited commands list
===
v5 -> v4:
1) Plenty of code refactoring based on Lianbo's comments on v4.
2) Removed the magic number when dealing with regs bitmap, see [6].
3) Rebased the patchset on top of latest upstream:
("1c6da3eaff8207 arm64: Fix bt command show wrong stacktrace on ramdump source")
v4 -> v3:
Fixed the author issue in [PATCH v3 06/16] Fix gdb_interface: restore gdb's
output streams at end of gdb_interface.
v3 -> v2:
1) Updated CC list as pointed out in [4]
2) Compiling issues as in [5]
v2 -> v1:
1) Added the patch: x86_64: Fix invalid input "=>" for bt command,
thanks for Kazu's testing.
2) Modify the patch: x86_64: Add gdb stack unwinding support, added the
pcp_save, spp_save and sp, for restoring the value in match of the original
code logic.
[1]: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg00469.html
[2]: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg00488.html
[3]: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg00554.html
[4]: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg00681.html
[5]: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg00715.html
[6]: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg00819.html
Aditya Gupta (2):
Remove 'frame' from prohibited commands list
ppc64: correct gdb passthroughs by implementing machdep->get_cpu_reg
Alexey Makhalov (2):
set_context(): check if context is already current
vmware_guestdump: Various format versions support
Tao Liu (10):
Leave only one gdb thread for crash
Let crash change gdb context
Rename get_cpu_reg to get_current_task_reg
Print task pid/command instead of CPU index
Fix gdb_interface: restore gdb's output streams at end of
gdb_interface
Stop stack unwinding at non-kernel address
x86_64: Add gdb stack unwinding support
Fix cpumask_t recursive dependence issue
x86_64: Fix invalid input "=>" for bt command
arm64: Add gdb stack unwinding support
arm64.c | 114 +++++++++++++++-
crash_target.c | 71 ++++++----
defs.h | 194 ++++++++++++++++++++++++++-
gdb-10.2.patch | 79 +++++++++++
gdb_interface.c | 35 ++---
kernel.c | 65 +++++++--
ppc64.c | 175 ++++++++++++++++++++++++-
symbols.c | 15 +++
task.c | 34 +++--
tools.c | 13 +-
unwind_x86_64.h | 4 -
vmware_guestdump.c | 316 +++++++++++++++++++++++++++++++-------------
x86_64.c | 319 ++++++++++++++++++++++++++++++++++++++++-----
xen_hyper.c | 2 +-
14 files changed, 1224 insertions(+), 212 deletions(-)
--
2.40.1
1 month
[PATCH v2] arm64: fix regression for the determination of section_size_bits
by qiwu.chen＠transsion.com
The commit 568c6f04 will cause a regression issue for the determination of
section_size_bits on kernel version before android12-5.10 or Linux-v5.12.
The section_size_bits is supposed to be compatible with linux upstream and
android GKI version:
Before android12-5.10 or Linux-v5.12:
SECTION_SIZE_BITS = 30
After android12-5.10 or Linux-v5.12:
SECTION_SIZE_BITS = 27 when defined 4K_PAGES or 16K_PAGES.
SECTION_SIZE_BITS = 29 when defined 64K_PAGES.
Introduce arm64_get_andriod_gki_version() to get Andriod GKI version by ut->release.
The Andriod GKI version is determined either by arm64_get_andriod_gki_version()
or the kernel config "CONFIG_ANDROID_KABI_RESERVE".
Fixes: 568c6f04 ("arm64: section_size_bits compatible with macro definitions")
Signed-off-by: qiwu.chen <qiwu.chen(a)transsion.com>
---
arm64.c | 68 ++++++++++++++++++++++++++++++++++++++++++---------------
1 file changed, 51 insertions(+), 17 deletions(-)
diff --git a/arm64.c b/arm64.c
index 78e6609..679f2ab 100644
--- a/arm64.c
+++ b/arm64.c
@@ -95,6 +95,13 @@ static void arm64_calc_KERNELPACMASK(void);
static void arm64_recalc_KERNELPACMASK(void);
static int arm64_get_vmcoreinfo(unsigned long *vaddr, const char *label, int base);
+/* Andriod GKI version definition */
+struct andriod_gki_version {
+ int kernel_version;
+ int kernel_patch_level;
+ int android_version;
+};
+
struct kernel_range {
unsigned long modules_vaddr, modules_end;
unsigned long vmalloc_start_addr, vmalloc_end;
@@ -1615,6 +1622,30 @@ arm64_calc_phys_offset(void)
fprintf(fp, "using %lx as phys_offset\n", ms->phys_offset);
}
+/*
+ * Determine Andriod GKI vmcore by reading "android" from ut->release.
+ * The prefix of Andriod GKI release version is:
+ * Kernel Version - Android release version
+ * For example:
+ * 5.10.209-android12, 5.15.148-android13
+ */
+static bool arm64_get_andriod_gki_version(struct andriod_gki_version *version)
+{
+ char *p;
+ struct new_utsname *uts = &kt->utsname;
+
+ if ((p = strstr(uts->release, "android"))) {
+ sscanf(uts->release, "%d.%d", &version->kernel_version, &version->kernel_patch_level);
+ sscanf(p, "android%d", &version->android_version);
+ if (CRASHDEBUG(1))
+ fprintf(fp, "andriod_gki_version: andriod%d-%d.%d\n",
+ version->android_version, version->kernel_version, version->kernel_patch_level);
+ return true;
+ }
+
+ return false;
+}
+
/*
* Determine SECTION_SIZE_BITS either by reading VMCOREINFO or the kernel
* config, otherwise use the 64-bit ARM default definiton.
@@ -1624,8 +1655,17 @@ arm64_get_section_size_bits(void)
{
int ret;
char *string;
+ bool is_ikconfig_avail;
+ struct andriod_gki_version ver = {0};
- if (THIS_KERNEL_VERSION >= LINUX(5,12,0)) {
+ if (arm64_get_vmcoreinfo(&machdep->section_size_bits, "NUMBER(SECTION_SIZE_BITS)", NUM_DEC))
+ goto exit;
+
+ is_ikconfig_avail = kt->ikconfig_flags & IKCONFIG_AVAIL ? TRUE : FALSE;
+ /* The commit reduce section size for arm64 sparsemem is introduced since linux-v5.12 and android-12-5.10 */
+ if (THIS_KERNEL_VERSION >= LINUX(5,12,0) ||
+ (is_ikconfig_avail && get_kernel_config("CONFIG_ANDROID_KABI_RESERVE", NULL) == IKCONFIG_Y) ||
+ (arm64_get_andriod_gki_version(&ver) && (ver.kernel_version * 100 + ver.kernel_patch_level >= 510) && ver.android_version >= 12)) {
if (machdep->pagesize == 65536)
machdep->section_size_bits = _SECTION_SIZE_BITS_5_12_64K;
else
@@ -1633,24 +1673,18 @@ arm64_get_section_size_bits(void)
} else
machdep->section_size_bits = _SECTION_SIZE_BITS;
- if (arm64_get_vmcoreinfo(&machdep->section_size_bits, "NUMBER(SECTION_SIZE_BITS)", NUM_DEC)) {
- /* nothing */
- } else if (kt->ikconfig_flags & IKCONFIG_AVAIL) {
- if ((ret = get_kernel_config("CONFIG_MEMORY_HOTPLUG", NULL)) == IKCONFIG_Y) {
- if ((ret = get_kernel_config("CONFIG_HOTPLUG_SIZE_BITS", &string)) == IKCONFIG_STR)
- machdep->section_size_bits = atol(string);
- }
-
- /* arm64: reduce section size for sparsemem */
- if ((ret = get_kernel_config("CONFIG_ARM64_4K_PAGES", NULL)) == IKCONFIG_Y
- || (ret = get_kernel_config("CONFIG_ARM64_16K_PAGES", NULL)) == IKCONFIG_Y)
- machdep->section_size_bits = _SECTION_SIZE_BITS_5_12;
- else if ((ret = get_kernel_config("CONFIG_ARM64_64K_PAGES", NULL)) == IKCONFIG_Y)
- machdep->section_size_bits = _SECTION_SIZE_BITS_5_12_64K;
+ /* section_size_bits for arm64 vendor special case */
+ if (is_ikconfig_avail && get_kernel_config("CONFIG_MEMORY_HOTPLUG", NULL) == IKCONFIG_Y) {
+ if (get_kernel_config("CONFIG_HOTPLUG_SIZE_BITS", &string) == IKCONFIG_STR)
+ machdep->section_size_bits = atol(string);
}
- if (CRASHDEBUG(1))
- fprintf(fp, "SECTION_SIZE_BITS: %ld\n", machdep->section_size_bits);
+exit:
+ if (machdep->section_size_bits) {
+ if (CRASHDEBUG(1))
+ fprintf(fp, "SECTION_SIZE_BITS: %ld\n", machdep->section_size_bits);
+ } else
+ error(FATAL, "cannot determine SECTION_SIZE_BITS\n");
}
/*
--
2.25.1
1 month, 1 week
seek error when loading /proc/kcore with type: "page_offset_base"
by Jose Fernandez
I'm trying to get crash to work on Arch Linux but I keep running into this error:
crash: seek error: kernel virtual address: ffffffff82b195c0 type: "page_offset_base"
I've the upstream 6.11RC and the latest CachyOS kernel (6.10.2). I boot into
the target kernel and then run crash with the respective vmlinux file. I'm
simply trying to load /proc/kcore with this command:
crash /usr/src/debug/linux-cachyos/vmlinux /proc/kcore -d10
Here is the full output:
crash 8.0.5
Copyright (C) 2002-2024 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006, 2010 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006, 2011, 2012 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005, 2011, 2020-2024 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
Copyright (C) 2015, 2021 VMware, 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.
get_live_memory_source: /proc/kcore
proc_kcore_data:
flags: 500 (KCORE_LOCAL|KCORE_ELF64)
segments: 28
elf_header: 64e6aab34860
header_size: 11828
notes64: 64e6aab348a0
load64: 64e6aab348d8
notes32: 0
load32: 0
vmcoreinfo: 0
size_vmcoreinfo: 0
Elf64_Phdr:
p_type: 4 (PT_NOTE)
p_flags: 0
p_offset: 698
p_vaddr: 0
p_paddr: 0
p_filesz: 10140
p_memsz: 0
p_align: 0
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: 7fffbc403000
p_vaddr: ffffffffbc400000
p_paddr: 915000000
p_filesz: 50528256
p_memsz: 50528256
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: 277fc0003000
p_vaddr: ffffa77fc0000000
p_paddr: ffffffffffffffff
p_filesz: 35184372088831
p_memsz: 35184372088831
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: 7fffc0003000
p_vaddr: ffffffffc0000000
p_paddr: ffffffffffffffff
p_filesz: 1056964608
p_memsz: 1056964608
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: fec00004000
p_vaddr: ffff8fec00001000
p_paddr: 1000
p_filesz: 651264
p_memsz: 651264
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: 727480003000
p_vaddr: fffff27480000000
p_paddr: ffffffffffffffff
p_filesz: 12288
p_memsz: 12288
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: fec00103000
p_vaddr: ffff8fec00100000
p_paddr: 100000
p_filesz: 162529280
p_memsz: 162529280
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: 727480007000
p_vaddr: fffff27480004000
p_paddr: ffffffffffffffff
p_filesz: 2539520
p_memsz: 2539520
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: fec09de4000
p_vaddr: ffff8fec09de1000
p_paddr: 9de1000
p_filesz: 1175552
p_memsz: 1175552
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: 72748027a000
p_vaddr: fffff27480277000
p_paddr: ffffffffffffffff
p_filesz: 20480
p_memsz: 20480
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: fec09f3f000
p_vaddr: ffff8fec09f3c000
p_paddr: 9f3c000
p_filesz: 169684992
p_memsz: 169684992
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: 72748027f000
p_vaddr: fffff2748027c000
p_paddr: ffffffffffffffff
p_filesz: 2658304
p_memsz: 2658304
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: fec18313000
p_vaddr: ffff8fec18310000
p_paddr: 18310000
p_filesz: 14557184
p_memsz: 14557184
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: 72748060f000
p_vaddr: fffff2748060c000
p_paddr: ffffffffffffffff
p_filesz: 229376
p_memsz: 229376
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: fec190f6000
p_vaddr: ffff8fec190f3000
p_paddr: 190f3000
p_filesz: 20480
p_memsz: 20480
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: fec190fc000
p_vaddr: ffff8fec190f9000
p_paddr: 190f9000
p_filesz: 29282304
p_memsz: 29282304
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: fec1acea000
p_vaddr: ffff8fec1ace7000
p_paddr: 1ace7000
p_filesz: 12288
p_memsz: 12288
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: 7274806b6000
p_vaddr: fffff274806b3000
p_paddr: ffffffffffffffff
p_filesz: 4096
p_memsz: 4096
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: fec1acee000
p_vaddr: ffff8fec1aceb000
p_paddr: 1aceb000
p_filesz: 143360
p_memsz: 143360
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: fec20e84000
p_vaddr: ffff8fec20e81000
p_paddr: 20e81000
p_filesz: 694374400
p_memsz: 694374400
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: 72748083d000
p_vaddr: fffff2748083a000
p_paddr: ffffffffffffffff
p_filesz: 10850304
p_memsz: 10850304
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: fec4a6fa000
p_vaddr: ffff8fec4a6f7000
p_paddr: 4a6f7000
p_filesz: 76910592
p_memsz: 76910592
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: 72748129e000
p_vaddr: fffff2748129b000
p_paddr: ffffffffffffffff
p_filesz: 1208320
p_memsz: 1208320
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: fec4f054000
p_vaddr: ffff8fec4f051000
p_paddr: 4f051000
p_filesz: 71499776
p_memsz: 71499776
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: fec58201000
p_vaddr: ffff8fec581fe000
p_paddr: 581fe000
p_filesz: 31371264
p_memsz: 31371264
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: 72748160a000
p_vaddr: fffff27481607000
p_paddr: ffffffffffffffff
p_filesz: 495616
p_memsz: 495616
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: fec59ff0000
p_vaddr: ffff8fec59fed000
p_paddr: 59fed000
p_filesz: 8192
p_memsz: 8192
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: fed00003000
p_vaddr: ffff8fed00000000
p_paddr: 100000000
p_filesz: 66004713472
p_memsz: 66004713472
p_align: 4096
Elf64_Phdr:
p_type: 1 (PT_LOAD)
p_flags: 7
p_offset: 727484003000
p_vaddr: fffff27484000000
p_paddr: ffffffffffffffff
p_filesz: 1031323648
p_memsz: 1031323648
p_align: 4096
Elf64_Nhdr:
n_namesz: 5 ("CORE")
n_descsz: 336
n_type: 1 (NT_PRSTATUS)
Elf64_Nhdr:
n_namesz: 5 ("CORE")
n_descsz: 136
n_type: 3 (NT_PRPSINFO)
Elf64_Nhdr:
n_namesz: 5 ("CORE")
n_descsz: 6360
n_type: 4 (NT_TASKSTRUCT)
Elf64_Nhdr:
n_namesz: 11 ("VMCOREINFO")
n_descsz: 3224
n_type: 0 (unknown)
OSRELEASE=6.10.2-2-cachyos
BUILD-ID=464ddea46107c047dd447fc06ce515bc716030fc
PAGESIZE=4096
SYMBOL(init_uts_ns)=ffffffffbe7c70c0
OFFSET(uts_namespace.name)=0
SYMBOL(node_online_map)=ffffffffbe81bb48
SYMBOL(swapper_pg_dir)=ffffffffbe620000
SYMBOL(_stext)=ffffffffbc400000
NUMBER(VMALLOC_START)=0xffffa77fc0000000
SYMBOL(vmemmap)=fffff27480000000
SYMBOL(mem_section)=ffff8ffc5e2f7000
LENGTH(mem_section)=2048
SIZE(mem_section)=16
OFFSET(mem_section.section_mem_map)=0
NUMBER(SECTION_SIZE_BITS)=27
NUMBER(MAX_PHYSMEM_BITS)=46
SIZE(page)=64
SIZE(pglist_data)=16704
SIZE(zone)=1728
SIZE(free_area)=104
SIZE(list_head)=16
SIZE(nodemask_t)=8
OFFSET(page.flags)=0
OFFSET(page._refcount)=52
OFFSET(page.mapping)=24
OFFSET(page.lru)=8
OFFSET(page._mapcount)=48
OFFSET(page.private)=40
OFFSET(page.compound_head)=8
OFFSET(pglist_data.node_zones)=0
OFFSET(pglist_data.nr_zones)=13792
OFFSET(pglist_data.node_start_pfn)=13800
OFFSET(pglist_data.node_spanned_pages)=13816
OFFSET(pglist_data.node_id)=13824
OFFSET(zone.free_area)=256
OFFSET(zone.vm_stat)=1536
OFFSET(zone.spanned_pages)=152
OFFSET(free_area.free_list)=0
OFFSET(list_head.next)=0
OFFSET(list_head.prev)=8
LENGTH(zone.free_area)=11
SYMBOL(prb)=ffffffffbe65b940
SYMBOL(printk_rb_static)=ffffffffbe65b960
SYMBOL(clear_seq)=ffffffffbf1351a0
SIZE(printk_ringbuffer)=88
OFFSET(printk_ringbuffer.desc_ring)=0
OFFSET(printk_ringbuffer.text_data_ring)=48
OFFSET(printk_ringbuffer.fail)=80
SIZE(prb_desc_ring)=48
OFFSET(prb_desc_ring.count_bits)=0
OFFSET(prb_desc_ring.descs)=8
OFFSET(prb_desc_ring.infos)=16
OFFSET(prb_desc_ring.head_id)=24
OFFSET(prb_desc_ring.tail_id)=32
SIZE(prb_desc)=24
OFFSET(prb_desc.state_var)=0
OFFSET(prb_desc.text_blk_lpos)=8
SIZE(prb_data_blk_lpos)=16
OFFSET(prb_data_blk_lpos.begin)=0
OFFSET(prb_data_blk_lpos.next)=8
SIZE(printk_info)=88
OFFSET(printk_info.seq)=0
OFFSET(printk_info.ts_nsec)=8
OFFSET(printk_info.text_len)=16
OFFSET(printk_info.caller_id)=20
OFFSET(printk_info.dev_info)=24
SIZE(dev_printk_info)=64
OFFSET(dev_printk_info.subsystem)=0
LENGTH(printk_info_subsystem)=16
OFFSET(dev_printk_info.device)=16
LENGTH(printk_info_device)=48
SIZE(prb_data_ring)=32
OFFSET(prb_data_ring.size_bits)=0
OFFSET(prb_data_ring.data)=8
OFFSET(prb_data_ring.head_lpos)=16
OFFSET(prb_data_ring.tail_lpos)=24
SIZE(atomic_long_t)=8
OFFSET(atomic_long_t.counter)=0
SIZE(latched_seq)=24
OFFSET(latched_seq.val)=8
LENGTH(free_area.free_list)=6
NUMBER(NR_FREE_PAGES)=0
NUMBER(PG_lru)=5
NUMBER(PG_private)=14
NUMBER(PG_swapcache)=11
NUMBER(PG_swapbacked)=18
NUMBER(PAGE_SLAB_MAPCOUNT_VALUE)=-4097
NUMBER(PG_hwpoison)=22
NUMBER(PG_head_mask)=64
NUMBER(PAGE_BUDDY_MAPCOUNT_VALUE)=-129
NUMBER(PAGE_HUGETLB_MAPCOUNT_VALUE)=-2049
NUMBER(PAGE_OFFLINE_MAPCOUNT_VALUE)=-257
SYMBOL(kallsyms_names)=ffffffffbda452f8
SYMBOL(kallsyms_num_syms)=ffffffffbda452f0
SYMBOL(kallsyms_token_table)=ffffffffbdc94af8
SYMBOL(kallsyms_token_index)=ffffffffbdc94e98
SYMBOL(kallsyms_offsets)=ffffffffbdc95098
SYMBOL(kallsyms_relative_base)=ffffffffbdd549d8
NUMBER(phys_base)=37996199936
SYMBOL(init_top_pgt)=ffffffffbe620000
NUMBER(pgtable_l5_enabled)=0
SYMBOL(node_data)=ffffffffbe81a620
LENGTH(node_data)=32
KERNELOFFSET=3b400000
NUMBER(KERNEL_IMAGE_SIZE)=1073741824
NUMBER(sme_mask)=0
/proc/version:
Linux version 6.10.2-2-cachyos (linux-cachyos@cachyos) (gcc (GCC) 14.1.1 20240720, GNU ld (GNU Binutils) 2.42.0) #1 SMP PREEMPT_DYNAMIC Sat, 27 Jul 2024 19:37:59 +0000
/usr/src/debug/linux-cachyos/vmlinux:
Linux version 6.10.2-2-cachyos (linux-cachyos@cachyos) (gcc (GCC) 14.1.1 20240720, GNU ld (GNU Binutils) 2.42.0) #1 SMP PREEMPT_DYNAMIC Sat, 27 Jul 2024 19:37:59 +0000
readmem: read_proc_kcore() -> /proc/kcore
crash: pv_ops exists: ARCH_PVOPS
VMCOREINFO: NUMBER(phys_base): 37996199936 -> 8d8c00000
gdb /usr/src/debug/linux-cachyos/vmlinux
GNU gdb (GDB) 10.2
Copyright (C) 2021 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 "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
GETBUF(344 -> 0)
GETBUF(1500 -> 1)
FREEBUF(1)
FREEBUF(0)
<readmem: ffffffff82b195c0, KVADDR, "page_offset_base", 8, (FOE|Q), 64e6a75445e8>
<read_proc_kcore: addr: ffffffff82b195c0 paddr: 8db7195c0 cnt: 8>
crash: seek error: kernel virtual address: ffffffff82b195c0 type: "page_offset_base"
[root@archlinux jose]#
1 month, 1 week
Re: [PATCH] arm64: fix the determination of vmemmap and struct_page_size
by lijiang
On Wed, Aug 7, 2024 at 11:31 AM <devel-request(a)lists.crash-utility.osci.io>
wrote:
> Date: Wed, 7 Aug 2024 11:47:48 +1200
> From: Tao Liu <ltao(a)redhat.com>
> Subject: [Crash-utility] Re: [PATCH] arm64: fix the determination of
> vmemmap and struct_page_size
> To: qiwu.chen(a)transsion.com
> Cc: devel(a)lists.crash-utility.osci.io
> Message-ID:
> <
> CAO7dBbXV3coyp14n94Ad1x2HRXt9+nZ8FAy6wai-2y-O50dAcQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi qiwu,
>
> On Mon, Jul 29, 2024 at 2:22 AM <qiwu.chen(a)transsion.com> wrote:
> >
> > Currently, the vmemmap ptr addr is determined by the vmcoreinfo of
> "SYMBOL(vmemmap)", which leads to an invalid vmemmap addr showed by "help
> -m" for dump files without the vmcoreinfo. The value of vmemmap_end is
> simply set to -1 for available VA_BITS_ACTUAL case in
> arm64_calc_virtual_memory_ranges(), and the struct_page_size value is 0.
> > crash> help -m |grep vmem
> > vmemmap_vaddr: fffffffeffe00000
> > vmemmap_end: ffffffffffffffff
> > vmemmap: 0000000000000000
> > crash> help -m |grep struct_page_size
> > struct_page_size: 0
> >
> > Introduce arm64_get_vmemmap_page_ptr() to fix the determination of
> vmemmap ptr addr, and fix the determination of vmemmap_end and
> struct_page_size in arm64_calc_virtual_memory_ranges().
> > crash> help -m |grep vmem
> > vmemmap_vaddr: fffffffeffe00000
> > vmemmap_end: ffffffffffe00000
> > vmemmap: fffffffefee00000
> > crash> help -m |grep struct_page_size
> > struct_page_size: 64
> >
> > Signed-off-by: qiwu.chen <qiwu.chen(a)qq.com>
> > ---
> > arm64.c | 29 +++++++++++++++++++++++------
> > 1 file changed, 23 insertions(+), 6 deletions(-)
> >
> > diff --git a/arm64.c b/arm64.c
> > index 78e6609..ef495ec 100644
> > --- a/arm64.c
> > +++ b/arm64.c
> > @@ -159,7 +159,6 @@ arm64_vmemmap_is_page_ptr(ulong addr, physaddr_t
> *phys)
> > ulong size = SIZE(page);
> > ulong pfn, nr;
> >
> > -
> > if (IS_SPARSEMEM() && (machdep->flags & VMEMMAP) &&
> > (addr >= VMEMMAP_VADDR && addr <= VMEMMAP_END) &&
> > !((addr - VMEMMAP_VADDR) % size)) {
> > @@ -175,6 +174,25 @@ arm64_vmemmap_is_page_ptr(ulong addr, physaddr_t
> *phys)
> > return FALSE;
> > }
> >
> > +static void arm64_get_vmemmap_page_ptr(void)
> > +{
> > + struct machine_specific *ms = machdep->machspec;
> > +
> > + /* If vmemmap exists, it means kernel enabled
> CONFIG_SPARSEMEM_VMEMMAP */
> > + if (arm64_get_vmcoreinfo(&ms->vmemmap, "SYMBOL(vmemmap)",
> NUM_HEX))
> > + goto out;
> > +
> > + /* The global symbol of vmemmap is removed since kernel commit
> 7bc1a0f9e1765 */
> > + if (!kernel_symbol_exists("vmemmap"))
> > + ms->vmemmap = ms->vmemmap_vaddr - ((ms->phys_offset >>
> machdep->pageshift) * ms->struct_page_size);
> > + else
> > + ms->vmemmap = symbol_value("vmemmap");
> > +
>
> I would prefer to exchange the if else sequence, to be:
>
> /* The global symbol of vmemmap is removed since kernel commit
> 7bc1a0f9e1765 */
> if (kernel_symbol_exists("vmemmap"))
> ms->vmemmap = symbol_value("vmemmap");
> else
> ms->vmemmap = ms->vmemmap_vaddr - ((ms->phys_offset >>
> machdep->pageshift) * ms->struct_page_size);
>
> This would be more readable, if a symbol exists, then read the symbol,
> otherwise calc it out.
>
> Other than that, the patch LGTM. Ack the rest of the patch.
>
Applied(with above change):
https://github.com/crash-utility/crash/commit/5cd1c6ace5fe41f3e007669d9bc...
Thanks
Lianbo
>
> Thanks,
> Tao Liu
>
> > +out:
> > + if (ms->vmemmap)
> > + machdep->is_page_ptr = arm64_vmemmap_is_page_ptr;
> > +}
> > +
> > /*
> > * Do all necessary machine-specific setup here. This is called several
> times
> > * during initialization.
> > @@ -443,10 +461,6 @@ arm64_init(int when)
> >
> > machdep->stacksize = ARM64_STACK_SIZE;
> > machdep->flags |= VMEMMAP;
> > - /* If vmemmap exists, it means kernel enabled
> CONFIG_SPARSEMEM_VMEMMAP */
> > - if (arm64_get_vmcoreinfo(&ms->vmemmap,
> "SYMBOL(vmemmap)", NUM_HEX))
> > - machdep->is_page_ptr = arm64_vmemmap_is_page_ptr;
> > -
> > machdep->uvtop = arm64_uvtop;
> > machdep->is_uvaddr = arm64_is_uvaddr;
> > machdep->eframe_search = arm64_eframe_search;
> > @@ -498,6 +512,7 @@ arm64_init(int when)
> > if (!ms->struct_page_size)
> > arm64_calc_virtual_memory_ranges();
> >
> > + arm64_get_vmemmap_page_ptr();
> > arm64_get_section_size_bits();
> >
> > if (!machdep->max_physmem_bits) {
> > @@ -4841,6 +4856,7 @@ arm64_calc_virtual_memory_ranges(void)
> > return;
> >
> > STRUCT_SIZE_INIT(page, "page");
> > + ms->struct_page_size = SIZE(page);
> >
> > switch (machdep->flags &
> (VM_L2_64K|VM_L3_64K|VM_L3_4K|VM_L4_4K))
> > {
> > @@ -4868,7 +4884,8 @@ arm64_calc_virtual_memory_ranges(void)
> > vmemmap_start = (-vmemmap_size - MEGABYTES(2));
> > ms->vmalloc_end = vmalloc_end - 1;
> > ms->vmemmap_vaddr = vmemmap_start;
> > - ms->vmemmap_end = -1;
> > + ms->vmemmap_end = vmemmap_start + vmemmap_size;
> > +
> > return;
> > }
> >
> > --
> > 2.25.1
>
1 month, 1 week
Re: [PATCH v2] Fix "irq -a" exceeding the memory range issue
by lijiang
Sorry, I almost missed v2, Tao.
On Wed, Jul 17, 2024 at 1:01 PM <devel-request(a)lists.crash-utility.osci.io>
wrote:
> Date: Wed, 17 Jul 2024 16:17:00 +1200
> From: Tao Liu <ltao(a)redhat.com>
> Subject: [Crash-utility] [PATCH v2] Fix "irq -a" exceeding the memory
> range issue
> To: devel(a)lists.crash-utility.osci.io
> Cc: Tao Liu <ltao(a)redhat.com>
> Message-ID: <20240717041659.14855-1-ltao(a)redhat.com>
> Content-Type: text/plain; charset="US-ASCII"; x-default=true
>
> Previously without the patch, there was an error observed as follows:
>
> crash> irq -a
> IRQ NAME AFFINITY
> 0 timer 0-191
> 4 ttyS0 0-23,96-119
> ...
> 84 smartpqi 72-73,168
> irq: page excluded: kernel virtual address: ffff97d03ffff000 type:
> "irq_desc affinity"
>
> The reason is the reading of irq affinity exceeded the memory range, see
> the following debug info:
>
> Thread 1 "crash" hit Breakpoint 1, generic_get_irq_affinity (irq=85) at
> kernel.c:7373
> 7375 irq_desc_addr = get_irq_desc_addr(irq);
> (gdb) p/x irq_desc_addr
> $1 = 0xffff97d03f21e800
>
> crash> struct irq_desc 0xffff97d03f21e800
> struct irq_desc {
> irq_common_data = {
> state_use_accessors = 425755136,
> node = 3,
> handler_data = 0x0,
> msi_desc = 0xffff97ca51b83480,
> affinity = 0xffff97d03fffee60,
> effective_affinity = 0xffff97d03fffe6c0
> },
>
> crash> whatis cpumask_t
> typedef struct cpumask {
> unsigned long bits[128];
> } cpumask_t;
> SIZE: 1024
>
> In order to get the affinity, crash will read the memory range
> 0xffff97d03fffee60
> ~ 0xffff97d03fffee60 + 1024(0x400) by line:
>
> readmem(affinity_ptr, KVADDR, affinity, len,
> "irq_desc affinity", FAULT_ON_ERROR);
>
> However the reading will exceed the effective memory range:
>
> crash> kmem 0xffff97d03fffee60
> CACHE OBJSIZE ALLOCATED TOTAL SLABS SSIZE NAME
> ffff97c900044400 32 123297 162944 1273 4k kmalloc-32
> SLAB MEMORY NODE TOTAL ALLOCATED FREE
> fffffca460ffff80 ffff97d03fffe000 3 128 81 47
> FREE / [ALLOCATED]
> [ffff97d03fffee60]
>
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> fffffca460ffff80 83fffe000 dead000000000001 ffff97d03fffe340 1
> d7ffffe0000800 slab
>
> crash> kmem ffff97d03ffff000
> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> fffffca460ffffc0 83ffff000 0 0 1 d7ffffe0004000
> reserved
>
> crash> dmesg
> ...
> [ 0.000000] BIOS-e820: [mem 0x00000000fe000000-0x00000000fe00ffff]
> reserved
> [ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000083fffefff]
> usable
> [ 0.000000] BIOS-e820: [mem 0x000000083ffff000-0x000000083fffffff]
> reserved
> ...
>
> The beginning physical address, aka 0x83fffe000, is located in the usable
> area and is readable, however the later physical address, starting from
> 0x83ffff000, is located in reserved region and not readable. In fact,
> the affinity member is allocated by alloc_cpumask_var_node(), for the 192
> CPUs
> system, the allocated size is only 24, and we can see it is within
> the kmalloc-32 slab. So it is incorrect to read 1024 length(given by
> STRUCT_SIZE("cpumask_t")), only 24 is enough.
>
> Since there are plenty of places in crash which takes the value of
> STRUCT_SIZE("cpumask_t"), and works fine for the past, this patch will
> not modify them all, only the one which encountered this issue(hunk in
> kernel.c), and the one with the same DIV_ROUND_UP() (hunk in tools.c).
>
> Signed-off-by: Tao Liu <ltao(a)redhat.com>
> ---
> v1 -> v2: modify the same hunk in tools.c
>
The v2 looks good to me.
Applied(with minor changes):
https://github.com/crash-utility/crash/commit/f615f8fab7bf3d2d5d5cb005181...
Lianbo
> ---
> kernel.c | 9 ++++++---
> tools.c | 11 ++++++++---
> 2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/kernel.c b/kernel.c
> index 8a9d498..464e877 100644
> --- a/kernel.c
> +++ b/kernel.c
> @@ -7362,7 +7362,7 @@ void
> generic_get_irq_affinity(int irq)
> {
> ulong irq_desc_addr;
> - long len;
> + long len, len_cpumask;
> ulong affinity_ptr;
> ulong *affinity;
> ulong tmp_addr;
> @@ -7382,8 +7382,11 @@ generic_get_irq_affinity(int irq)
> if (!action)
> return;
>
> - if ((len = STRUCT_SIZE("cpumask_t")) < 0)
> - len = DIV_ROUND_UP(kt->cpus, BITS_PER_LONG) *
> sizeof(ulong);
> + len = DIV_ROUND_UP(kt->cpus, BITS_PER_LONG) * sizeof(ulong);
> + len_cpumask = STRUCT_SIZE("cpumask_t");
> + if (len_cpumask > 0) {
> + len = len_cpumask > len ? len : len_cpumask;
> + }
>
> affinity = (ulong *)GETBUF(len);
> if (VALID_MEMBER(irq_common_data_affinity))
> diff --git a/tools.c b/tools.c
> index 1022d57..fab0f83 100644
> --- a/tools.c
> +++ b/tools.c
> @@ -6718,9 +6718,14 @@ swap64(uint64_t val, int swap)
> ulong *
> get_cpumask_buf(void)
> {
> - int cpulen;
> - if ((cpulen = STRUCT_SIZE("cpumask_t")) < 0)
> - cpulen = DIV_ROUND_UP(kt->cpus, BITS_PER_LONG) *
> sizeof(ulong);
> + int cpulen, len_cpumask;
> +
> + cpulen = DIV_ROUND_UP(kt->cpus, BITS_PER_LONG) * sizeof(ulong);
> + len_cpumask = STRUCT_SIZE("cpumask_t");
> + if (len_cpumask > 0) {
> + cpulen = len_cpumask > cpulen ? cpulen : len_cpumask;
> + }
> +
> return (ulong *)GETBUF(cpulen);
> }
>
> --
> 2.40.1
>
1 month, 1 week
[PATCH] LoongArch64: fix incorrect code in the main()
by Lianbo Jiang
The commit c3939d2e1930 contains incorrect code that starts with "+",
for example:
- !machine_type("S390X") && !machine_type("RISCV64"))
+ !machine_type("S390X") && !machine_type("RISCV64") &&
++ !machine_type("LOONGARCH64"))
See the main() in the main.c
...
} else if (STREQ(long_options[option_index].name, "kaslr")) {
if (!machine_type("X86_64") &&
!machine_type("ARM64") && !machine_type("X86") &&
!machine_type("S390X") && !machine_type("RISCV64") &&
+ !machine_type("LOONGARCH64"))
Let's remove it from the main().
Link: https://lists.crash-utility.osci.io/archives/list/devel@lists.crash-utili...
Fixes: c3939d2e1930 ("LoongArch64: Add "--kaslr" command line option support")
Signed-off-by: Lianbo Jiang <lijiang(a)redhat.com>
---
main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/main.c b/main.c
index 0b6b9273ab06..71bcc1558192 100644
--- a/main.c
+++ b/main.c
@@ -229,7 +229,7 @@ main(int argc, char **argv)
if (!machine_type("X86_64") &&
!machine_type("ARM64") && !machine_type("X86") &&
!machine_type("S390X") && !machine_type("RISCV64") &&
-+ !machine_type("LOONGARCH64"))
+ !machine_type("LOONGARCH64"))
error(INFO, "--kaslr not valid "
"with this machine type.\n");
else if (STREQ(optarg, "auto"))
--
2.45.1
1 month, 1 week
[PATCH] arm64: fix the determination of vmemmap and struct_page_size
by qiwu.chen＠transsion.com
Currently, the vmemmap ptr addr is determined by the vmcoreinfo of "SYMBOL(vmemmap)", which leads to an invalid vmemmap addr showed by "help -m" for dump files without the vmcoreinfo. The value of vmemmap_end is simply set to -1 for available VA_BITS_ACTUAL case in arm64_calc_virtual_memory_ranges(), and the struct_page_size value is 0.
crash> help -m |grep vmem
vmemmap_vaddr: fffffffeffe00000
vmemmap_end: ffffffffffffffff
vmemmap: 0000000000000000
crash> help -m |grep struct_page_size
struct_page_size: 0
Introduce arm64_get_vmemmap_page_ptr() to fix the determination of vmemmap ptr addr, and fix the determination of vmemmap_end and struct_page_size in arm64_calc_virtual_memory_ranges().
crash> help -m |grep vmem
vmemmap_vaddr: fffffffeffe00000
vmemmap_end: ffffffffffe00000
vmemmap: fffffffefee00000
crash> help -m |grep struct_page_size
struct_page_size: 64
Signed-off-by: qiwu.chen <qiwu.chen(a)qq.com>
---
arm64.c | 29 +++++++++++++++++++++++------
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/arm64.c b/arm64.c
index 78e6609..ef495ec 100644
--- a/arm64.c
+++ b/arm64.c
@@ -159,7 +159,6 @@ arm64_vmemmap_is_page_ptr(ulong addr, physaddr_t *phys)
ulong size = SIZE(page);
ulong pfn, nr;
-
if (IS_SPARSEMEM() && (machdep->flags & VMEMMAP) &&
(addr >= VMEMMAP_VADDR && addr <= VMEMMAP_END) &&
!((addr - VMEMMAP_VADDR) % size)) {
@@ -175,6 +174,25 @@ arm64_vmemmap_is_page_ptr(ulong addr, physaddr_t *phys)
return FALSE;
}
+static void arm64_get_vmemmap_page_ptr(void)
+{
+ struct machine_specific *ms = machdep->machspec;
+
+ /* If vmemmap exists, it means kernel enabled CONFIG_SPARSEMEM_VMEMMAP */
+ if (arm64_get_vmcoreinfo(&ms->vmemmap, "SYMBOL(vmemmap)", NUM_HEX))
+ goto out;
+
+ /* The global symbol of vmemmap is removed since kernel commit 7bc1a0f9e1765 */
+ if (!kernel_symbol_exists("vmemmap"))
+ ms->vmemmap = ms->vmemmap_vaddr - ((ms->phys_offset >> machdep->pageshift) * ms->struct_page_size);
+ else
+ ms->vmemmap = symbol_value("vmemmap");
+
+out:
+ if (ms->vmemmap)
+ machdep->is_page_ptr = arm64_vmemmap_is_page_ptr;
+}
+
/*
* Do all necessary machine-specific setup here. This is called several times
* during initialization.
@@ -443,10 +461,6 @@ arm64_init(int when)
machdep->stacksize = ARM64_STACK_SIZE;
machdep->flags |= VMEMMAP;
- /* If vmemmap exists, it means kernel enabled CONFIG_SPARSEMEM_VMEMMAP */
- if (arm64_get_vmcoreinfo(&ms->vmemmap, "SYMBOL(vmemmap)", NUM_HEX))
- machdep->is_page_ptr = arm64_vmemmap_is_page_ptr;
-
machdep->uvtop = arm64_uvtop;
machdep->is_uvaddr = arm64_is_uvaddr;
machdep->eframe_search = arm64_eframe_search;
@@ -498,6 +512,7 @@ arm64_init(int when)
if (!ms->struct_page_size)
arm64_calc_virtual_memory_ranges();
+ arm64_get_vmemmap_page_ptr();
arm64_get_section_size_bits();
if (!machdep->max_physmem_bits) {
@@ -4841,6 +4856,7 @@ arm64_calc_virtual_memory_ranges(void)
return;
STRUCT_SIZE_INIT(page, "page");
+ ms->struct_page_size = SIZE(page);
switch (machdep->flags & (VM_L2_64K|VM_L3_64K|VM_L3_4K|VM_L4_4K))
{
@@ -4868,7 +4884,8 @@ arm64_calc_virtual_memory_ranges(void)
vmemmap_start = (-vmemmap_size - MEGABYTES(2));
ms->vmalloc_end = vmalloc_end - 1;
ms->vmemmap_vaddr = vmemmap_start;
- ms->vmemmap_end = -1;
+ ms->vmemmap_end = vmemmap_start + vmemmap_size;
+
return;
}
--
2.25.1
1 month, 1 week
Re: [PATCH] arm64: fix the determination of vmemmap and struct_page_size
by lijiang
On Sun, Jul 28, 2024 at 10:23 PM <devel-request(a)lists.crash-utility.osci.io>
wrote:
> Date: Sun, 28 Jul 2024 14:21:58 -0000
> From: qiwu.chen(a)transsion.com
> Subject: [Crash-utility] [PATCH] arm64: fix the determination of
> vmemmap and struct_page_size
> To: devel(a)lists.crash-utility.osci.io
> Message-ID: <20240728142158.17290.96096(a)lists.crash-utility.osci.io>
> Content-Type: text/plain; charset="utf-8"
>
> Currently, the vmemmap ptr addr is determined by the vmcoreinfo of
> "SYMBOL(vmemmap)", which leads to an invalid vmemmap addr showed by "help
> -m" for dump files without the vmcoreinfo. The value of vmemmap_end is
> simply set to -1 for available VA_BITS_ACTUAL case in
> arm64_calc_virtual_memory_ranges(), and the struct_page_size value is 0.
> crash> help -m |grep vmem
> vmemmap_vaddr: fffffffeffe00000
> vmemmap_end: ffffffffffffffff
> vmemmap: 0000000000000000
> crash> help -m |grep struct_page_size
> struct_page_size: 0
>
> Introduce arm64_get_vmemmap_page_ptr() to fix the determination of vmemmap
> ptr addr, and fix the determination of vmemmap_end and struct_page_size in
> arm64_calc_virtual_memory_ranges().
> crash> help -m |grep vmem
> vmemmap_vaddr: fffffffeffe00000
> vmemmap_end: ffffffffffe00000
> vmemmap: fffffffefee00000
> crash> help -m |grep struct_page_size
> struct_page_size: 64
>
>
Thank you for the improvement, qiwu.
And it looks good to me, so: Ack.
Lianbo
> Signed-off-by: qiwu.chen <qiwu.chen(a)qq.com>
> ---
> arm64.c | 29 +++++++++++++++++++++++------
> 1 file changed, 23 insertions(+), 6 deletions(-)
>
> diff --git a/arm64.c b/arm64.c
> index 78e6609..ef495ec 100644
> --- a/arm64.c
> +++ b/arm64.c
> @@ -159,7 +159,6 @@ arm64_vmemmap_is_page_ptr(ulong addr, physaddr_t *phys)
> ulong size = SIZE(page);
> ulong pfn, nr;
>
> -
> if (IS_SPARSEMEM() && (machdep->flags & VMEMMAP) &&
> (addr >= VMEMMAP_VADDR && addr <= VMEMMAP_END) &&
> !((addr - VMEMMAP_VADDR) % size)) {
> @@ -175,6 +174,25 @@ arm64_vmemmap_is_page_ptr(ulong addr, physaddr_t
> *phys)
> return FALSE;
> }
>
> +static void arm64_get_vmemmap_page_ptr(void)
> +{
> + struct machine_specific *ms = machdep->machspec;
> +
> + /* If vmemmap exists, it means kernel enabled
> CONFIG_SPARSEMEM_VMEMMAP */
> + if (arm64_get_vmcoreinfo(&ms->vmemmap, "SYMBOL(vmemmap)", NUM_HEX))
> + goto out;
> +
> + /* The global symbol of vmemmap is removed since kernel commit
> 7bc1a0f9e1765 */
> + if (!kernel_symbol_exists("vmemmap"))
> + ms->vmemmap = ms->vmemmap_vaddr - ((ms->phys_offset >>
> machdep->pageshift) * ms->struct_page_size);
> + else
> + ms->vmemmap = symbol_value("vmemmap");
> +
> +out:
> + if (ms->vmemmap)
> + machdep->is_page_ptr = arm64_vmemmap_is_page_ptr;
> +}
> +
> /*
> * Do all necessary machine-specific setup here. This is called several
> times
> * during initialization.
> @@ -443,10 +461,6 @@ arm64_init(int when)
>
> machdep->stacksize = ARM64_STACK_SIZE;
> machdep->flags |= VMEMMAP;
> - /* If vmemmap exists, it means kernel enabled
> CONFIG_SPARSEMEM_VMEMMAP */
> - if (arm64_get_vmcoreinfo(&ms->vmemmap, "SYMBOL(vmemmap)",
> NUM_HEX))
> - machdep->is_page_ptr = arm64_vmemmap_is_page_ptr;
> -
> machdep->uvtop = arm64_uvtop;
> machdep->is_uvaddr = arm64_is_uvaddr;
> machdep->eframe_search = arm64_eframe_search;
> @@ -498,6 +512,7 @@ arm64_init(int when)
> if (!ms->struct_page_size)
> arm64_calc_virtual_memory_ranges();
>
> + arm64_get_vmemmap_page_ptr();
> arm64_get_section_size_bits();
>
> if (!machdep->max_physmem_bits) {
> @@ -4841,6 +4856,7 @@ arm64_calc_virtual_memory_ranges(void)
> return;
>
> STRUCT_SIZE_INIT(page, "page");
> + ms->struct_page_size = SIZE(page);
>
> switch (machdep->flags & (VM_L2_64K|VM_L3_64K|VM_L3_4K|VM_L4_4K))
> {
> @@ -4868,7 +4884,8 @@ arm64_calc_virtual_memory_ranges(void)
> vmemmap_start = (-vmemmap_size - MEGABYTES(2));
> ms->vmalloc_end = vmalloc_end - 1;
> ms->vmemmap_vaddr = vmemmap_start;
> - ms->vmemmap_end = -1;
> + ms->vmemmap_end = vmemmap_start + vmemmap_size;
> +
> return;
> }
>
> --
> 2.25.1
>
1 month, 1 week
Re: [PATCH] arm64: Introduction of support for 16K page with 3-level table support
by lijiang
On Mon, Aug 5, 2024 at 9:31 AM <devel-request(a)lists.crash-utility.osci.io>
wrote:
> Date: Sun, 04 Aug 2024 05:46:17 -0000
> From: kuan-ying.lee(a)canonical.com
> Subject: [Crash-utility] Re: [PATCH] arm64: Introduction of support
> for 16K page with 3-level table support
> To: devel(a)lists.crash-utility.osci.io
> Message-ID: <20240804054617.17290.54860(a)lists.crash-utility.osci.io>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Lijiang and Tao,
>
> Thanks for taking look at this patch.
>
> I use kernel-6.10 to build arm64 kernel.
> I modify arch/arm64/configs/defconfig with the following diff.
>
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 2c7bf4da0b80..f981095a4440 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -1682,12 +1682,10 @@ CONFIG_CMA_SIZE_MBYTES=32
> CONFIG_PRINTK_TIME=y
> CONFIG_DEBUG_KERNEL=y
> CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
> -CONFIG_DEBUG_INFO_REDUCED=y
> CONFIG_MAGIC_SYSRQ=y
> CONFIG_DEBUG_FS=y
> # CONFIG_SCHED_DEBUG is not set
> # CONFIG_DEBUG_PREEMPT is not set
> -# CONFIG_FTRACE is not set
> CONFIG_CORESIGHT=m
> CONFIG_CORESIGHT_LINK_AND_SINK_TMC=m
> CONFIG_CORESIGHT_CATU=m
> @@ -1697,3 +1695,7 @@ CONFIG_CORESIGHT_STM=m
> CONFIG_CORESIGHT_CPU_DEBUG=m
> CONFIG_CORESIGHT_CTI=m
> CONFIG_MEMTEST=y
> +CONFIG_GDB_SCRIPTS=y
> +CONFIG_STACKTRACE=y
> +CONFIG_ARM64_VA_BITS_47=y
> +CONFIG_ARM64_16K_PAGES=y
>
>
Thank you for sharing this, Kuan-Ying.
I tried to build the latest upstream kernel on another machine(with the
va_bits 47 and 16k_pages configs), it works.
The code changes are fine to me, and I do not see any new issues in my
tests.
Just one thing, there is an indentation issue in the
arm64_vtop_3level_16k(), but I can help to correct it(when merging).
For the patch: Ack
Thanks
Lianbo
I can boot up with qemu-system-aarch64 and after booting up, I run the
> "echo c > /proc/sysrq-trigger" in qemu to produce the
> vmcore.
>
> After I get vmcore, I can use crash-tool to debug vmcore and vmlinux.
>
> Thank you,
> Kuan-Ying Lee
>
1 month, 2 weeks
Re: [PATCH] arm64: Introduction of support for 16K page with 3-level table support
by lijiang
On Fri, Aug 2, 2024 at 2:13 PM <devel-request(a)lists.crash-utility.osci.io>
wrote:
> Date: Thu, 1 Aug 2024 18:30:36 +1200
> From: Tao Liu <ltao(a)redhat.com>
> Subject: [Crash-utility] Re: [PATCH] arm64: Introduction of support
> for 16K page with 3-level table support
> To: kuan-ying.lee(a)canonical.com
> Cc: devel(a)lists.crash-utility.osci.io
> Message-ID:
> <CAO7dBbVR-7t24f8=
> h07QF-Hxdo_D1NdijUDZHngvkUYiMqpiJA(a)mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi kuan-ying,
>
> On Thu, Jul 25, 2024 at 2:53 PM Tao Liu <ltao(a)redhat.com> wrote:
> >
> > Hi Kuan-Ying,
> >
> > On Thu, Jul 25, 2024 at 2:44 PM <kuan-ying.lee(a)canonical.com> wrote:
> > >
> > > Hi crash maintainers,
> > >
> > > Could you please help review this patch that supports 16K page size
> with a 3-level page table and 47 bits?
> > >
>
> I don't have much comments for this patch, it looks good so far.
> However I'd like to have the patch tested. I'm wondering if there are
> linux distros which have enabled 16K page, or can I just compile the
> kernel source with 16K page config enabled on any distro like fedora?
> I guess there might be problems for makedumpfile when creating vmcore
> of 16K page. Any suggestions?
>
>
I tried to build the latest kernel 6.11.0 with the 16k page and 47 va bits
option, but it failed to boot.
Could you please share the test steps? Kuan-Ying
Thanks
Lianbo
Thanks,
> Tao Liu
>
1 month, 2 weeks