[Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

[Dave Anderson]

----- Original Message -----

> > > > > 3) Backtracing a 'panic'ed task fails:
> > > > >  crash> bt
> > > > >  PID: 999    TASK: ffffffe960081800  CPU: 0   COMMAND: "sh"
> > > > >  bt: WARNING: corrupt prstatus? pstate=0x80000000, but no user frame found
> > > > >  bt: WARNING: cannot determine starting stack frame for task ffffffe960081800
> > > > > 
> > > > >   frame->pc indicates that it is a kernel address, so obviously something
> > > > >   is wrong. I'm diggin into it.
> > > > 
> > > > Can you add a debug statement that displays frame->pc, frame->sp, and frame->fp?
> > > 
> > > I've already identified the cause.
> > > pt_regs->pstate was set mistakenly from "sprsr_el1" in panic().
> > > But I have a difficulty here to fix the problem as we have no direct way
> > > to retrieve a value of the *current* PSTATE.
> >  
> > Interesting.  I don't know what you mean by "sprsr_el1" in panic(), but

> > I just got a report from my github "issues", where the user injected a panic()
> > call into a kernel module and got the same error as above because of the pstate
> > value.  I asked him to put this hack into arm64.c:
> 
> spspr_el1 is a register that holds a value of PSTATE when an exception
> is trapped into EL1. Since panic() is called even in case of software
> bugs, it is not useful anyway.
> Currently I'm trying to save a "faked" current PSTATE into pt_regs->pstate
> and will add this fix in my next kdump patch series (v17).

OK thanks.  Mystery solved.  I think I'll still add the hack-around that prints
the warning message but allows it to continue if the sp, fp and pc appear correct.
It used to do that, but the new behavior was actually a regression that was 
introduced as part of this patch in crash-7.1.5:

    Fix for the "bt" command to properly pull the stack and frame pointer
    registers from the NT_PRSTATUS notes of 32-bit tasks running in
    user-mode on ARM64.  Without the patch, the "bt" command utilizes
    ptregs->sp and ptregs->regs[29] for 32-bit tasks instead of the
    architecturally-mapped ptregs->regs[13] and ptregs->regs[11], which
    yields unpredictable/invalid results, and possibly a segmentation
    violation.
    (drjones at redhat.com)

Thanks,
  Dave