----- 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@xxxxxxxxxx)
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
