On Tue, Feb 22, 2022 at 10:19 AM HAGIO KAZUHITO(萩尾 一仁)
<k-hagio-ab@xxxxxxx> wrote:
>
> Hi Pingfan,
>
> thanks for the patch.
>
> -----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. This is fine
> > since there is no access to vmalloced area at this early stage.
> >
> > Signed-off-by: Pingfan Liu <piliu@xxxxxxxxxx>
> > ---
> > arm64.c | 17 +++++++++++++++++
> > defs.h | 1 +
> > kernel.c | 3 +++
> > 3 files changed, 21 insertions(+)
> >
> > diff --git a/arm64.c b/arm64.c
> > index 4f2c2b5..4aa971c 100644
> > --- a/arm64.c
> > +++ b/arm64.c
> > @@ -92,6 +92,21 @@ static void arm64_calc_VA_BITS(void);
> > static int arm64_is_uvaddr(ulong, struct task_context *);
> > static void arm64_calc_KERNELPACMASK(void);
> >
> > +/* called by kernel_init() */
> > +static void arm64_post_kernel_init(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
> > @@ -104,6 +119,7 @@ arm64_init(int when)
> > char *string;
> > struct machine_specific *ms;
> >
> > + arch_post_kernel_init = arm64_post_kernel_init;
>
> Why is the arch_post_kernel_init needed, i.e. can't we put it in
> machdep_init(POST_GDB)?
>
Yeah, it is better to handle this issue in that place.
Thanks for the suggestion and I will send out V2 soon.
Regards,
Pingfan
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/crash-utility
