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

> > > > 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).