Re: [Crash-utility] [PATCHv2] arm64: deduce the start address of kernel code, based on kernel version
On Thu, Feb 24, 2022 at 2:37 PM HAGIO KAZUHITO(萩尾 一仁)
<k-hagio-ab(a)nec.com> wrote:
-----Original Message-----
> 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(a)redhat.com>
Thanks for the v2. Assuming the patch was tested,
Yes, it is tested. Without it, crash can encounter the following issue
crash> foreach bt
...
PID: 0 TASK: ffff000805635780 CPU: 8 COMMAND: "swapper/8"
bt: page excluded: kernel virtual address: ffff800010040000 type:
"IRQ stack contents"
bt: read of IRQ stack at ffff800010040000 failed
#0 [ffff800013ecbdd0] arch_cpu_idle at ffff800010c31238
#1 [ffff800013ecbde0] default_idle_call at ffff800010c3d8a8
#2 [ffff800013ecbe00] cpuidle_idle_call at ffff800010125bc8
#3 [ffff800013ecbe40] do_idle at ffff800010125cf8
#4 [ffff800013ecbe70] cpu_startup_entry at ffff800010125f4c
#5 [ffff800013ecbe90] secondary_start_kernel at ffff800010064f18
PID: 0 TASK: ffff000805632300 CPU: 9 COMMAND: "swapper/9"
bt: page excluded: kernel virtual address: ffff800010048000 type:
"IRQ stack contents"
bt: read of IRQ stack at ffff800010048000 failed
#0 [ffff800013ed3dd0] arch_cpu_idle at ffff800010c31238
#1 [ffff800013ed3de0] default_idle_call at ffff800010c3d8a8
#2 [ffff800013ed3e00] cpuidle_idle_call at ffff800010125bc8
#3 [ffff800013ed3e40] do_idle at ffff800010125cf8
#4 [ffff800013ed3e70] cpu_startup_entry at ffff800010125f4c
#5 [ffff800013ed3e90] secondary_start_kernel at ffff800010064f1
After this patch, it is gone.
Thanks,
Pingfan
Acked-by: Kazuhito Hagio <k-hagio-ab(a)nec.com>
Kazu
> ---
> arm64.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/arm64.c b/arm64.c
> index de1038a..3ab8489 100644
> --- a/arm64.c
> +++ b/arm64.c
> @@ -92,6 +92,20 @@ static void arm64_calc_VA_BITS(void);
> static int arm64_is_uvaddr(ulong, struct task_context *);
> static void arm64_calc_KERNELPACMASK(void);
>
> +static void arm64_calc_kernel_start(void)
> +{
> + struct machine_specific *ms = machdep->machspec;
> + struct syment *sp;
> +
> + if (THIS_KERNEL_VERSION >= LINUX(5,11,0))
> + sp = kernel_symbol_search("_stext");
> + else
> + sp = kernel_symbol_search("_text");
> +
> + ms->kimage_text = (sp ? sp->value : 0);
> + sp = kernel_symbol_search("_end");
> + ms->kimage_end = (sp ? sp->value : 0);
> +}
>
> /*
> * Do all necessary machine-specific setup here. This is called several times
> @@ -241,6 +255,7 @@ arm64_init(int when)
> if (machdep->flags & NEW_VMEMMAP) {
> struct syment *sp;
>
> + /* It is finally decided in arm64_calc_kernel_start() */
> sp = kernel_symbol_search("_text");
> ms->kimage_text = (sp ? sp->value : 0);
> sp = kernel_symbol_search("_end");
> @@ -387,6 +402,8 @@ arm64_init(int when)
> break;
>
> case POST_GDB:
> + /* Rely on kernel version to decide the kernel start address */
> + arm64_calc_kernel_start();
> arm64_calc_virtual_memory_ranges();
> arm64_get_section_size_bits();
>
> --
> 2.31.1