Message-ID: <3fbfaa49-8ee9-a65c-133b-d0f072f0eb6c@microchip.com>
Date:   Tue, 9 Aug 2022 21:13:05 +0000
From:   <Conor.Dooley@...rochip.com>
To:     <xianting.tian@...ux.alibaba.com>, <paul.walmsley@...ive.com>,
        <palmer@...belt.com>, <aou@...s.berkeley.edu>,
        <anup@...infault.org>, <heiko@...ech.de>, <guoren@...nel.org>,
        <mick@....forth.gr>, <alexandre.ghiti@...onical.com>,
        <bhe@...hat.com>, <vgoyal@...hat.com>, <dyoung@...hat.com>,
        <corbet@....net>, <Conor.Dooley@...rochip.com>
CC:     <kexec@...ts.infradead.org>, <linux-doc@...r.kernel.org>,
        <linux-riscv@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <crash-utility@...hat.com>, <huanyi.xj@...baba-inc.com>,
        <heinrich.schuchardt@...onical.com>, <k-hagio-ab@....com>,
        <hschauhan@...ltrace.org>, <yixun.lan@...il.com>
Subject: Re: [PATCH V5 4/6] RISC-V: Fixup getting correct current pc

On 02/08/2022 13:18, Xianting Tian wrote:
> When use 'echo c > /proc/sysrq-trigger' to trigger kdump, riscv_crash_save_regs()
> will be called to save regs to vmcore, we found "epc" value 00ffffffa5537400
> is not a valid kernel virtual address, but is a user virtual address. Other
> regs(eg, ra, sp, gp...) are correct kernel virtual address.
> Actually 0x00ffffffb0dd9400 is the user mode PC of 'PID: 113 Comm: sh', which
> is saved in the task's stack.
> 
> [   21.201701] CPU: 0 PID: 113 Comm: sh Kdump: loaded Not tainted 5.18.9 #45
> [   21.201979] Hardware name: riscv-virtio,qemu (DT)
> [   21.202160] epc : 00ffffffa5537400 ra : ffffffff80088640 sp : ff20000010333b90
> [   21.202435]  gp : ffffffff810dde38 tp : ff6000000226c200 t0 : ffffffff8032be7c
> [   21.202707]  t1 : 0720072007200720 t2 : 30203a7375746174 s0 : ff20000010333cf0
> [   21.202973]  s1 : 0000000000000000 a0 : ff20000010333b98 a1 : 0000000000000001
> [   21.203243]  a2 : 0000000000000010 a3 : 0000000000000000 a4 : 28c8f0aeffea4e00
> [   21.203519]  a5 : 28c8f0aeffea4e00 a6 : 0000000000000009 a7 : ffffffff8035c9b8
> [   21.203794]  s2 : ffffffff810df0a8 s3 : ffffffff810df718 s4 : ff20000010333b98
> [   21.204062]  s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80c4a468
> [   21.204331]  s8 : 00ffffffef451410 s9 : 0000000000000007 s10: 00aaaaaac0510700
> [   21.204606]  s11: 0000000000000001 t3 : ff60000001218f00 t4 : ff60000001218f00
> [   21.204876]  t5 : ff60000001218000 t6 : ff200000103338b8
> [   21.205079] status: 0000000200000020 badaddr: 0000000000000000 cause: 0000000000000008
> 
> With the incorrect PC, the backtrace showed by crash tool as below, the first
> stack frame is abnormal,
> 
> crash> bt
> PID: 113      TASK: ff60000002269600  CPU: 0    COMMAND: "sh"
>  #0 [ff2000001039bb90] __efistub_.Ldebug_info0 at 00ffffffa5537400 <-- Abnormal
>  #1 [ff2000001039bcf0] panic at ffffffff806578ba
>  #2 [ff2000001039bd50] sysrq_reset_seq_param_set at ffffffff8038c030
>  #3 [ff2000001039bda0] __handle_sysrq at ffffffff8038c5f8
>  #4 [ff2000001039be00] write_sysrq_trigger at ffffffff8038cad8
>  #5 [ff2000001039be20] proc_reg_write at ffffffff801b7edc
>  #6 [ff2000001039be40] vfs_write at ffffffff80152ba6
>  #7 [ff2000001039be80] ksys_write at ffffffff80152ece
>  #8 [ff2000001039bed0] sys_write at ffffffff80152f46
> 
> With the patch, we can get current kernel mode PC, the output as below,
> 
> [   17.607658] CPU: 0 PID: 113 Comm: sh Kdump: loaded Not tainted 5.18.9 #42
> [   17.607937] Hardware name: riscv-virtio,qemu (DT)
> [   17.608150] epc : ffffffff800078f8 ra : ffffffff8008862c sp : ff20000010333b90
> [   17.608441]  gp : ffffffff810dde38 tp : ff6000000226c200 t0 : ffffffff8032be68
> [   17.608741]  t1 : 0720072007200720 t2 : 666666666666663c s0 : ff20000010333cf0
> [   17.609025]  s1 : 0000000000000000 a0 : ff20000010333b98 a1 : 0000000000000001
> [   17.609320]  a2 : 0000000000000010 a3 : 0000000000000000 a4 : 0000000000000000
> [   17.609601]  a5 : ff60000001c78000 a6 : 000000000000003c a7 : ffffffff8035c9a4
> [   17.609894]  s2 : ffffffff810df0a8 s3 : ffffffff810df718 s4 : ff20000010333b98
> [   17.610186]  s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80c4a468
> [   17.610469]  s8 : 00ffffffca281410 s9 : 0000000000000007 s10: 00aaaaaab5bb6700
> [   17.610755]  s11: 0000000000000001 t3 : ff60000001218f00 t4 : ff60000001218f00
> [   17.611041]  t5 : ff60000001218000 t6 : ff20000010333988
> [   17.611255] status: 0000000200000020 badaddr: 0000000000000000 cause: 0000000000000008
> 
> With the correct PC, the backtrace showed by crash tool as below,
> 
> crash> bt
> PID: 113      TASK: ff6000000226c200  CPU: 0    COMMAND: "sh"
>  #0 [ff20000010333b90] riscv_crash_save_regs at ffffffff800078f8 <--- Normal
>  #1 [ff20000010333cf0] panic at ffffffff806578c6
>  #2 [ff20000010333d50] sysrq_reset_seq_param_set at ffffffff8038c03c
>  #3 [ff20000010333da0] __handle_sysrq at ffffffff8038c604
>  #4 [ff20000010333e00] write_sysrq_trigger at ffffffff8038cae4
>  #5 [ff20000010333e20] proc_reg_write at ffffffff801b7ee8
>  #6 [ff20000010333e40] vfs_write at ffffffff80152bb2
>  #7 [ff20000010333e80] ksys_write at ffffffff80152eda
>  #8 [ff20000010333ed0] sys_write at ffffffff80152f52
> 
> Fixes: e53d28180d4d ("RISC-V: Add kdump support")

This patch is also a fix, but not at the start of the series which
(I think) makes it less likely to be picked up for an auto-backport.

As it doesn't seem to depend on the prior patches, can you move this
up to 2/6 in the series?

> Co-developed-by: Guo Ren <guoren@...nel.org>
> Signed-off-by: Xianting Tian <xianting.tian@...ux.alibaba.com>
> ---
>  arch/riscv/kernel/crash_save_regs.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/kernel/crash_save_regs.S b/arch/riscv/kernel/crash_save_regs.S
> index 7832fb763aba..b2a1908c0463 100644
> --- a/arch/riscv/kernel/crash_save_regs.S
> +++ b/arch/riscv/kernel/crash_save_regs.S
> @@ -44,7 +44,7 @@ SYM_CODE_START(riscv_crash_save_regs)
>  	REG_S t6,  PT_T6(a0)	/* x31 */
>  
>  	csrr t1, CSR_STATUS
> -	csrr t2, CSR_EPC
> +	auipc t2, 0x0
>  	csrr t3, CSR_TVAL
>  	csrr t4, CSR_CAUSE
>  

Powered by blists - more mailing lists