Re: [PATCHv2] arm64: deduce the start address of kernel code, based on kernel version

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Fedora Development]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]

 

Powered by Linux