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")
Co-developed-by: Guo Ren <[email protected]>
Signed-off-by: Xianting Tian <[email protected]>
---
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
--
2.17.1
On 09/08/2022 22:13, [email protected] wrote:
> 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?
>
Plus, it'd be nice if the subject gave some more sub component context
& the same applies to most of the patches in the series.
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 <[email protected]>
> Signed-off-by: Xianting Tian <[email protected]>
> ---
> 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
>