Hi,Lianbo
Thank you for your feedback.
My kernel version is 5.10.59, and this issue is happened when the
ramdumps without vmcoreinfo.
I guess your scene may have vmcore,the following logic helps to
correctly locate MODULES/VMALLOC ranges with right kernel version.
279 ms->kimage_end = (sp ? sp->value : 0);
280
281 if (ms->struct_page_size && (r =
arm64_get_va_range(ms))) {------------->//If there is a vmcore, it
will go to the following codes
282 /* We can get all the
MODULES/VMALLOC/VMEMMAP ranges now.*/
283 ms->modules_vaddr = r->modules_vaddr;
284 ms->modules_end =
r->modules_end - 1;
285 ms->vmalloc_start_addr =
r->vmalloc_start_addr;
286 ms->vmalloc_end =
r->vmalloc_end - 1;
287 ms->vmemmap_vaddr = r->vmemmap_vaddr;
288 ms->vmemmap_end =
r->vmemmap_end - 1;
289 } else if (ms->VA_BITS_ACTUAL)
{------------>//unable to locate the version and other information
through vmcore
}
lijiang <lijiang(a)redhat.com> 于2022年6月29日周三 14:21写道:
Hi, Qianli
On Tue, Jun 28, 2022 at 9:55 AM lijiang <lijiang(a)redhat.com> wrote:
>
> Hi, Kazu and Qianli
>
> On Tue, Jun 28, 2022 at 9:17 AM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab(a)nec.com>
wrote:
>>
>> Hi Qianli,
>>
>> thanks for the patch and explanation. I was off.
>>
>> On 2022/06/27 11:24, qianli zhao wrote:
>> > Hi,Kazu
>> >
>> > Would you like to help review this patch?
>>
>> Sure, I think I can review it this week.
>>
>> Lianbo, can you possibly reproduce and test this?
>
>
> OK, I will have a look and give feedback later.
Could you please point out the kernel version? I tried it with the latest kernel and did
not reproduce this issue when disabling the kaslr feature(# CONFIG_RANDOMIZE_BASE is not
set or nokaslr)
crash > help -m
..
vmalloc_start_addr: ffff800008000000
vmalloc_end: fffffbffefffffff
modules_vaddr: ffff800000000000
modules_end: ffff800007ffffff
vmemmap_vaddr: fffffc0000000000
vmemmap_end: fffffdffffffffff
...
And the following information is dumped from the kernel(commit: 941e3e791269)
...
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] modules : 0xffff800000000000 - 0xffff800008000000 ( 128 MB)
[ 0.000000] vmalloc : 0xffff800008000000 - 0xfffffbfff0000000 (126975 GB)
...
[ 0.000000] vmemmap : 0xfffffc0000000000 - 0xfffffe0000000000 ( 2048 GB
maximum)
[ 0.000000] 0xfffffc000000bc00 - 0xfffffc023df40000 ( 9183 MB
actual)
I'm wondering if that can be only reproduced on the old kernel, right? Or did I miss
anything else?
Thanks.
Lianbo
>
>>
>> Kazu
>>
>> >
>> > qianli zhao <zhaoqianligood(a)gmail.com> 于2022年6月24日周五 10:56写道:
>> >
>> >>
>> >> Hi,all
>> >>
>> >> Here's some explanation for this patch
>> >>
>> >> Without patch:
>> >> Consider the following scenario
>> >> ->arm64_init(PRE_GDB)
>> >> case PRE_GDB:
>> >> ...
>> >> 292 } else if (ms->VA_BITS_ACTUAL) {
>> >> 293 ms->modules_vaddr =
>> >> (st->_stext_vmlinux & TEXT_OFFSET_MASK) -
>> >> ARM64_MODULES_VSIZE;-->//ms->modules_vaddr=0xfffffffff8000000
>> >> 294 ms->modules_end =
>> >> ms->modules_vaddr + ARM64_MODULES_VSIZE
>> >> -1;--->//ms->modules_end=0xffffffffffffffff
>> >> 295 ms->vmalloc_start_addr =
>> >> ms->modules_end + 1;--->//ms->vmalloc_start_addr=0
>> >> 296 } else {
>> >> ....
>> >> }
>> >> arm64_calc_kimage_voffset();
>> >> .....
>> >>
>> >> Since arm64_calc_kimage_voffset() depends on vmalloc_start_addr,
>> >> kimage_voffset cannot be calculated correctly.
>> >>
>> >> st->_stext_vmlinux can be initialized in numeric_forward(),just set
>> >> st->_stext_vmlinux to UNINITIALIZED.
>> >>
>> >> ============
>> >> log as below:
>> >>
>> >> $ ~/crash/crash/crash vmlinux DDRCS0.bin@0x80000000 --machdep
vabits_actual=48
>> >>
>> >> crash 8.0.1++
>> >> Copyright (C) 2002-2022 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-2022 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.
>> >>
>> >> NOTE: setting vabits_actual to: 48
>> >>
>> >> WARNING: kimage_voffset cannot be determined from the dumpfile.
>> >> Try using the command line option: --machdep
kimage_voffset=<addr>
>> >> 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 "--host=x86_64-pc-linux-gnu
>> >> --target=aarch64-elf-linux".
>> >> 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"...
>> >>
>> >> crash: read error: kernel virtual address: ffff80001083d4a0 type:
>> >> "kernel_config_data"
>> >> WARNING: cannot read kernel_config_data
>> >> crash: read error: kernel virtual address: ffff80001170e798 type:
"possible"
>> >> WARNING: cannot read cpu_possible_map
>> >> crash: read error: kernel virtual address: ffff80001170e7a8 type:
"present"
>> >> WARNING: cannot read cpu_present_map
>> >> crash: read error: kernel virtual address: ffff80001170e788 type:
"online"
>> >> WARNING: cannot read cpu_online_map
>> >> crash: read error: kernel virtual address: ffff80001170e7c0 type:
"active"
>> >> WARNING: cannot read cpu_active_map
>> >> crash: read error: kernel virtual address: ffff8000122e00f0 type:
>> >> "shadow_timekeeper xtime_sec"
>> >> crash: read error: kernel virtual address: ffff80001171dc04 type:
"init_uts_ns"
>> >> crash: vmlinux and /var/tmp/ramdump_elf_m2ivkg do not match!
>> >>
>> >> Usage:
>> >>
>> >> crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS] (dumpfile
form)
>> >> crash [OPTION]... [NAMELIST] (live system
form)
>> >>
>> >> Enter "crash -h" for details.
>> >>
>> >> Qianli Zhao <zhaoqianligood(a)gmail.com> 于2022年6月24日周五 00:14写道:
>> >>>
>> >>> From: Qianli Zhao <qianli.zhao(a)horizon.ai>
>> >>>
>> >>> Setting st->_stext_vmlinux to UNINITIALIZED to search for
"_stext" from the vmlinux
>> >>> Without the patch, if we do not enable kaslr, will get the wrong
>> >>> MODULES/VMALLOC ranges, cause parsing dump failure
>> >>>
>> >>> Signed-off-by: Qianli Zhao <qianli.zhao(a)horizon.ai>
>> >>> ---
>> >>> arm64.c | 3 +++
>> >>> 1 file changed, 3 insertions(+)
>> >>>
>> >>> diff --git a/arm64.c b/arm64.c
>> >>> index 0f615cf..4458a66 100644
>> >>> --- a/arm64.c
>> >>> +++ b/arm64.c
>> >>> @@ -149,6 +149,9 @@ arm64_init(int when)
>> >>>
>> >>> ms = machdep->machspec;
>> >>>
>> >>> + if (ms->VA_BITS_ACTUAL)
>> >>> + st->_stext_vmlinux = UNINITIALIZED;
>> >>> +
>> >>> if (!ms->kimage_voffset &&
STREQ(pc->live_memsrc, "/dev/crash"))
>> >>> ioctl(pc->mfd, DEV_CRASH_ARCH_DATA,
&ms->kimage_voffset);
>> >>>
>> >>> --
>> >>> 2.17.1
>> >>>