On Thu, Feb 24, 2022 at 2:37 PM HAGIO KAZUHITO(萩尾 一仁)
<k-hagio-ab@xxxxxxx> 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@xxxxxxxxxx>
>
> 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@xxxxxxx>
>
> 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
>
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/crash-utility
