7:18 a.m.
I ever sent the patch 1 in the link:
https://patchwork.kernel.org/project/linux-riscv/patch/20220708073150.352...
And patch 2,3 in the link:
https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367...
https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367...
This patch set just put these patches together, and with three new patch 4, 5, 6.
these six patches are the fixups for machine_kexec, kernel mode PC for vmcore
and improvements for vmcoreinfo, memory layout dump and fixup chedule out issue
in machine_crash_shutdown().
The main changes in the six patchs as below,
Patch 1: use __smp_processor_id() instead of smp_processor_id() to cleanup
the console prints.
Patch 2: Add VM layout, va bits, ram base to vmcoreinfo, which can simplify
the development of crash tool as ARM64 already did
(arch/arm64/kernel/crash_core.c).
Patch 3: Add modules to virtual kernel memory layout dump.
Patch 4: Fixup to get correct kernel mode PC for vmcore.
Patch 5: Updates vmcoreinfo.rst.
Patch 6: Fixup schedule out issue in machine_crash_shutdown()
With these six patches(patch 2 is must), crash tool can work well to analyze
a vmcore. The patches for crash tool for RISCV64 is in the link:
https://lore.kernel.org/linux-riscv/20220801043040.2003264-1-xianting.tia...
------
Changes v1 -> v2:
1, remove the patch "Add a fast call path of crash_kexec()" from this series
of patches, as it already applied to riscv git.
https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?h...
2, add 'Reviewed-by' based on the comments of v1.
Changes v2 -> v3:
use "riscv" instead of "riscv64" in patch 5 subject line.
Changes v3 -> v4:
use "riscv" instead of "riscv64" in the summary of patch 5 subject
line.
Changes v4 -> v5:
add a new patch "RISC-V: Fixup schedule out issue in machine_crash_shutdown()"
Xianting Tian (6):
RISC-V: use __smp_processor_id() instead of smp_processor_id()
RISC-V: Add arch_crash_save_vmcoreinfo support
riscv: Add modules to virtual kernel memory layout dump
RISC-V: Fixup getting correct current pc
riscv: crash_core: Export kernel vm layout, phys_ram_base
RISC-V: Fixup schedule out issue in machine_crash_shutdown()
.../admin-guide/kdump/vmcoreinfo.rst | 31 +++++++++++++++++++
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/crash_core.c | 29 +++++++++++++++++
arch/riscv/kernel/crash_save_regs.S | 2 +-
arch/riscv/kernel/machine_kexec.c | 28 ++++++++++++++---
arch/riscv/mm/init.c | 4 +++
6 files changed, 89 insertions(+), 6 deletions(-)
create mode 100644 arch/riscv/kernel/crash_core.c
--
2.17.1
7:18 a.m.
New subject: [PATCH V5 1/6] RISC-V: use __smp_processor_id() instead of smp_processor_id()
Use __smp_processor_id() to avoid check the preemption context when
CONFIG_DEBUG_PREEMPT enabled, as we will enter crash kernel and no
return.
Without the patch,
[ 103.781044] sysrq: Trigger a crash
[ 103.784625] Kernel panic - not syncing: sysrq triggered crash
[ 103.837634] CPU1: off
[ 103.889668] CPU2: off
[ 103.933479] CPU3: off
[ 103.939424] Starting crashdump kernel...
[ 103.943442] BUG: using smp_processor_id() in preemptible [00000000] code: sh/346
[ 103.950884] caller is debug_smp_processor_id+0x1c/0x26
[ 103.956051] CPU: 0 PID: 346 Comm: sh Kdump: loaded Not tainted
5.10.113-00002-gce03f03bf4ec-dirty #149
[ 103.965355] Call Trace:
[ 103.967805] [<ffffffe00020372a>] walk_stackframe+0x0/0xa2
[ 103.973206] [<ffffffe000bcf1f4>] show_stack+0x32/0x3e
[ 103.978258] [<ffffffe000bd382a>] dump_stack_lvl+0x72/0x8e
[ 103.983655] [<ffffffe000bd385a>] dump_stack+0x14/0x1c
[ 103.988705] [<ffffffe000bdc8fe>] check_preemption_disabled+0x9e/0xaa
[ 103.995057] [<ffffffe000bdc926>] debug_smp_processor_id+0x1c/0x26
[ 104.001150] [<ffffffe000206c64>] machine_kexec+0x22/0xd0
[ 104.006463] [<ffffffe000291a7e>] __crash_kexec+0x6a/0xa4
[ 104.011774] [<ffffffe000bcf3fa>] panic+0xfc/0x2b0
[ 104.016480] [<ffffffe000656ca4>] sysrq_reset_seq_param_set+0x0/0x70
[ 104.022745] [<ffffffe000657310>] __handle_sysrq+0x8c/0x154
[ 104.028229] [<ffffffe0006577e8>] write_sysrq_trigger+0x5a/0x6a
[ 104.034061] [<ffffffe0003d90e0>] proc_reg_write+0x58/0xd4
[ 104.039459] [<ffffffe00036cff4>] vfs_write+0x7e/0x254
[ 104.044509] [<ffffffe00036d2f6>] ksys_write+0x58/0xbe
[ 104.049558] [<ffffffe00036d36a>] sys_write+0xe/0x16
[ 104.054434] [<ffffffe000201b9a>] ret_from_syscall+0x0/0x2
[ 104.067863] Will call new kernel at ecc00000 from hart id 0
[ 104.074939] FDT image at fc5ee000
[ 104.079523] Bye...
With the patch we can got clear output,
[ 67.740553] sysrq: Trigger a crash
[ 67.744166] Kernel panic - not syncing: sysrq triggered crash
[ 67.809123] CPU1: off
[ 67.865210] CPU2: off
[ 67.909075] CPU3: off
[ 67.919123] Starting crashdump kernel...
[ 67.924900] Will call new kernel at ecc00000 from hart id 0
[ 67.932045] FDT image at fc5ee000
[ 67.935560] Bye...
Fixes: 0e105f1d0037 ("riscv: use hart id instead of cpu id on machine_kexec")
Reviewed-by: Guo Ren <guoren(a)kernel.org>
Reviewed-by: Heiko Stuebner <heiko(a)sntech.de>
Reviewed-by: Atish Patra <atishp(a)rivosinc.com>
Signed-off-by: Xianting Tian <xianting.tian(a)linux.alibaba.com>
---
arch/riscv/kernel/machine_kexec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/kernel/machine_kexec.c b/arch/riscv/kernel/machine_kexec.c
index df8e24559035..86d1b5f9dfb5 100644
--- a/arch/riscv/kernel/machine_kexec.c
+++ b/arch/riscv/kernel/machine_kexec.c
@@ -171,7 +171,7 @@ machine_kexec(struct kimage *image)
struct kimage_arch *internal = &image->arch;
unsigned long jump_addr = (unsigned long) image->start;
unsigned long first_ind_entry = (unsigned long) &image->head;
- unsigned long this_cpu_id = smp_processor_id();
+ unsigned long this_cpu_id = __smp_processor_id();
unsigned long this_hart_id = cpuid_to_hartid_map(this_cpu_id);
unsigned long fdt_addr = internal->fdt_addr;
void *control_code_buffer = page_address(image->control_code_page);
--
2.17.1
4:10 p.m.
New subject: [PATCH V5 1/6] RISC-V: use __smp_processor_id() instead of smp_processor_id()
On 02/08/2022 13:18, Xianting Tian wrote:
[PATCH V5 1/6] RISC-V: use __smp_processor_id() instead of
smp_processor_id()
FWIW this subject is very non specific - its not easy to tell what
it's about. How about something something like:
RISC-V: kexec: fix use of smp_processor_id() in preemptible context
Use __smp_processor_id() to avoid check the preemption context when
CONFIG_DEBUG_PREEMPT enabled, as we will enter crash kernel and no
return.
Without the patch,
[ 103.781044] sysrq: Trigger a crash
[ 103.784625] Kernel panic - not syncing: sysrq triggered crash
[ 103.837634] CPU1: off
[ 103.889668] CPU2: off
[ 103.933479] CPU3: off
[ 103.939424] Starting crashdump kernel...
[ 103.943442] BUG: using smp_processor_id() in preemptible [00000000] code: sh/346
[ 103.950884] caller is debug_smp_processor_id+0x1c/0x26
[ 103.956051] CPU: 0 PID: 346 Comm: sh Kdump: loaded Not tainted
5.10.113-00002-gce03f03bf4ec-dirty #149
[ 103.965355] Call Trace:
[ 103.967805] [<ffffffe00020372a>] walk_stackframe+0x0/0xa2
[ 103.973206] [<ffffffe000bcf1f4>] show_stack+0x32/0x3e
[ 103.978258] [<ffffffe000bd382a>] dump_stack_lvl+0x72/0x8e
[ 103.983655] [<ffffffe000bd385a>] dump_stack+0x14/0x1c
[ 103.988705] [<ffffffe000bdc8fe>] check_preemption_disabled+0x9e/0xaa
[ 103.995057] [<ffffffe000bdc926>] debug_smp_processor_id+0x1c/0x26
[ 104.001150] [<ffffffe000206c64>] machine_kexec+0x22/0xd0
[ 104.006463] [<ffffffe000291a7e>] __crash_kexec+0x6a/0xa4
[ 104.011774] [<ffffffe000bcf3fa>] panic+0xfc/0x2b0
[ 104.016480] [<ffffffe000656ca4>] sysrq_reset_seq_param_set+0x0/0x70
[ 104.022745] [<ffffffe000657310>] __handle_sysrq+0x8c/0x154
[ 104.028229] [<ffffffe0006577e8>] write_sysrq_trigger+0x5a/0x6a
[ 104.034061] [<ffffffe0003d90e0>] proc_reg_write+0x58/0xd4
[ 104.039459] [<ffffffe00036cff4>] vfs_write+0x7e/0x254
[ 104.044509] [<ffffffe00036d2f6>] ksys_write+0x58/0xbe
[ 104.049558] [<ffffffe00036d36a>] sys_write+0xe/0x16
[ 104.054434] [<ffffffe000201b9a>] ret_from_syscall+0x0/0x2
[ 104.067863] Will call new kernel at ecc00000 from hart id 0
[ 104.074939] FDT image at fc5ee000
[ 104.079523] Bye...
With the patch we can got clear output,
[ 67.740553] sysrq: Trigger a crash
[ 67.744166] Kernel panic - not syncing: sysrq triggered crash
[ 67.809123] CPU1: off
[ 67.865210] CPU2: off
[ 67.909075] CPU3: off
[ 67.919123] Starting crashdump kernel...
[ 67.924900] Will call new kernel at ecc00000 from hart id 0
[ 67.932045] FDT image at fc5ee000
[ 67.935560] Bye...
Fixes: 0e105f1d0037 ("riscv: use hart id instead of cpu id on machine_kexec")
Reviewed-by: Guo Ren <guoren(a)kernel.org>
Reviewed-by: Heiko Stuebner <heiko(a)sntech.de>
Reviewed-by: Atish Patra <atishp(a)rivosinc.com>
Signed-off-by: Xianting Tian <xianting.tian(a)linux.alibaba.com>
---
arch/riscv/kernel/machine_kexec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/kernel/machine_kexec.c b/arch/riscv/kernel/machine_kexec.c
index df8e24559035..86d1b5f9dfb5 100644
--- a/arch/riscv/kernel/machine_kexec.c
+++ b/arch/riscv/kernel/machine_kexec.c
@@ -171,7 +171,7 @@ machine_kexec(struct kimage *image)
struct kimage_arch *internal = &image->arch;
unsigned long jump_addr = (unsigned long) image->start;
unsigned long first_ind_entry = (unsigned long) &image->head;
- unsigned long this_cpu_id = smp_processor_id();
+ unsigned long this_cpu_id = __smp_processor_id();
unsigned long this_hart_id = cpuid_to_hartid_map(this_cpu_id);
unsigned long fdt_addr = internal->fdt_addr;
void *control_code_buffer = page_address(image->control_code_page);
7:18 a.m.
New subject: [PATCH V5 2/6] RISC-V: Add arch_crash_save_vmcoreinfo support
Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
VMEMMAP and KERNEL_LINK_ADDR ranges), va bits and ram base to vmcore.
Default pagetable levels and PAGE_OFFSET aren't same for different kernel
version as below. For default pagetable levels, it sets sv57 on defaultly
in latest kernel and do fallback to try to set sv48 on boot time if sv57
is not supported in current hardware.
For ram base, the default value is 0x80200000 for qemu riscv64 env, 0x200000
for riscv64 SoC platform(eg, SoC platform of RISC-V XuanTie 910 CPU).
* Linux Kernel 5.18 ~
* PGTABLE_LEVELS = 5
* PAGE_OFFSET = 0xff60000000000000
* Linux Kernel 5.17 ~
* PGTABLE_LEVELS = 4
* PAGE_OFFSET = 0xffffaf8000000000
* Linux Kernel 4.19 ~
* PGTABLE_LEVELS = 3
* PAGE_OFFSET = 0xffffffe000000000
Since these configurations change from time to time and version to version,
it is preferable to export them via vmcoreinfo than to change the crash's
code frequently, it can simplify the development of crash tool.
Signed-off-by: Xianting Tian <xianting.tian(a)linux.alibaba.com>
---
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/crash_core.c | 29 +++++++++++++++++++++++++++++
2 files changed, 30 insertions(+)
create mode 100644 arch/riscv/kernel/crash_core.c
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index 33bb60a354cd..5e149df58176 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB) += kgdb.o
obj-$(CONFIG_KEXEC_CORE) += kexec_relocate.o crash_save_regs.o machine_kexec.o
obj-$(CONFIG_KEXEC_FILE) += elf_kexec.o machine_kexec_file.o
obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
+obj-$(CONFIG_CRASH_CORE) += crash_core.o
obj-$(CONFIG_JUMP_LABEL) += jump_label.o
diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c
new file mode 100644
index 000000000000..8d7f5ff108da
--- /dev/null
+++ b/arch/riscv/kernel/crash_core.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <linux/crash_core.h>
+#include <linux/pagemap.h>
+
+void arch_crash_save_vmcoreinfo(void)
+{
+ VMCOREINFO_NUMBER(VA_BITS);
+ VMCOREINFO_NUMBER(phys_ram_base);
+
+ vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);
+ vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);
+ vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);
+ vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);
+ vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);
+#ifdef CONFIG_64BIT
+ vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
+ vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
+#endif
+
+ if (IS_ENABLED(CONFIG_64BIT)) {
+#ifdef CONFIG_KASAN
+ vmcoreinfo_append_str("NUMBER(KASAN_SHADOW_START)=0x%lx\n",
KASAN_SHADOW_START);
+ vmcoreinfo_append_str("NUMBER(KASAN_SHADOW_END)=0x%lx\n", KASAN_SHADOW_END);
+#endif
+ vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);
+ vmcoreinfo_append_str("NUMBER(ADDRESS_SPACE_END)=0x%lx\n",
ADDRESS_SPACE_END);
+ }
+}
--
2.17.1
7:18 a.m.
New subject: [PATCH V5 3/6] riscv: Add modules to virtual kernel memory layout dump
Modules always live before the kernel, MODULES_END is fixed but
MODULES_VADDR isn't fixed, it depends on the kernel size.
Let's add it to virtual kernel memory layout dump.
As MODULES is only defined for CONFIG_64BIT, so we dump it when
CONFIG_64BIT=y.
eg,
MODULES_VADDR - MODULES_END
0xffffffff01133000 - 0xffffffff80000000
Reviewed-by: Guo Ren <guoren(a)kernel.org>
Reviewed-by: Heiko Stuebner <heiko(a)sntech.de>
Signed-off-by: Xianting Tian <xianting.tian(a)linux.alibaba.com>
---
arch/riscv/mm/init.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index d466ec670e1f..2c4a64e97aec 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -135,6 +135,10 @@ static void __init print_vm_layout(void)
(unsigned long)VMEMMAP_END);
print_ml("vmalloc", (unsigned long)VMALLOC_START,
(unsigned long)VMALLOC_END);
+#ifdef CONFIG_64BIT
+ print_ml("modules", (unsigned long)MODULES_VADDR,
+ (unsigned long)MODULES_END);
+#endif
print_ml("lowmem", (unsigned long)PAGE_OFFSET,
(unsigned long)high_memory);
if (IS_ENABLED(CONFIG_64BIT)) {
--
2.17.1
7:18 a.m.
New subject: [PATCH V5 4/6] RISC-V: Fixup getting correct current pc
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 <guoren(a)kernel.org>
Signed-off-by: Xianting Tian <xianting.tian(a)linux.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
--
2.17.1
4:13 p.m.
New subject: [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(a)kernel.org>
Signed-off-by: Xianting Tian <xianting.tian(a)linux.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
4:14 p.m.
New subject: [PATCH V5 4/6] RISC-V: Fixup getting correct current pc
On 09/08/2022 22:13, Conor.Dooley(a)microchip.com 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.
7:18 a.m.
New subject: [PATCH V5 5/6] riscv: crash_core: Export kernel vm layout, phys_ram_base
These infos are needed by the kdump crash tool. Since these values change
from time to time, it is preferable to export them via vmcoreinfo than to
change the crash's code frequently.
Signed-off-by: Xianting Tian <xianting.tian(a)linux.alibaba.com>
---
.../admin-guide/kdump/vmcoreinfo.rst | 31 +++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst
b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index 8419019b6a88..6b76284a503c 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -595,3 +595,34 @@ X2TLB
-----
Indicates whether the crashed kernel enabled SH extended mode.
+
+RISCV64
+=======
+
+VA_BITS
+-------
+
+The maximum number of bits for virtual addresses. Used to compute the
+virtual memory ranges.
+
+PAGE_OFFSET
+-----------
+
+Indicates the virtual kernel start address of direct-mapped RAM region.
+
+phys_ram_base
+-------------
+
+Indicates the start physical RAM address.
+
+MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END
+-----------------------------------------------------------------------------
+KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END
+----------------------------------------------------------------------
+
+Used to get the correct ranges:
+ MODULES_VADDR ~ MODULES_END : Kernel module space.
+ VMALLOC_START ~ VMALLOC_END : vmalloc() / ioremap() space.
+ VMEMMAP_START ~ VMEMMAP_END : vmemmap region, used for struct page array.
+ KASAN_SHADOW_START ~ KASAN_SHADOW_END : kasan shadow space.
+ KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END : Kernel link and BPF space.
--
2.17.1
4:20 p.m.
New subject: [PATCH V5 5/6] riscv: crash_core: Export kernel vm layout, phys_ram_base
On 02/08/2022 13:18, Xianting Tian wrote:
riscv: crash_core: Export kernel vm layout, phys_ram_base
Can you please just use RISC-V: for the whole series, my OCD
hates the mix haha.
These infos are needed by the kdump crash tool. Since these values
change
from time to time, it is preferable to export them via vmcoreinfo than to
change the crash's code frequently.
This commit description doesn't seem to match the patches at all.
I don't see any exporting happening here at all - this is documenting
the export. Maybe I am just misunderstanding, but this commit message
just doesn't seem to match the change. Secondly, should the subject not
be something like "docs: admin-guide: add riscv crash kernel yada yada"?
Maybe the current subject lime that explains the lack of a review from
the docs maintainer?
Thanks,
Conor.
Signed-off-by: Xianting Tian <xianting.tian(a)linux.alibaba.com>
---
.../admin-guide/kdump/vmcoreinfo.rst | 31 +++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst
b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index 8419019b6a88..6b76284a503c 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -595,3 +595,34 @@ X2TLB
-----
Indicates whether the crashed kernel enabled SH extended mode.
+
+RISCV64
+=======
+
+VA_BITS
+-------
+
+The maximum number of bits for virtual addresses. Used to compute the
+virtual memory ranges.
+
+PAGE_OFFSET
+-----------
+
+Indicates the virtual kernel start address of direct-mapped RAM region.
+
+phys_ram_base
+-------------
+
+Indicates the start physical RAM address.
+
+MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END
+-----------------------------------------------------------------------------
+KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END
+----------------------------------------------------------------------
+
+Used to get the correct ranges:
+ MODULES_VADDR ~ MODULES_END : Kernel module space.
+ VMALLOC_START ~ VMALLOC_END : vmalloc() / ioremap() space.
+ VMEMMAP_START ~ VMEMMAP_END : vmemmap region, used for struct page array.
+ KASAN_SHADOW_START ~ KASAN_SHADOW_END : kasan shadow space.
+ KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END : Kernel link and BPF space.
7 a.m.
New subject: [PATCH V5 5/6] riscv: crash_core: Export kernel vm layout, phys_ram_base
在 2022/8/10 上午5:20, Conor.Dooley(a)microchip.com 写道:
On 02/08/2022 13:18, Xianting Tian wrote:
> riscv: crash_core: Export kernel vm layout, phys_ram_base
Can you please just use RISC-V: for the whole series, my OCD
hates the mix haha.
Sorry, I missed it, you ever pointed out this poblem in the comments of
V3, I will definitely fix the issue in V6.
> These infos are needed by the kdump crash tool. Since these values change
> from time to time, it is preferable to export them via vmcoreinfo than to
> change the crash's code frequently.
This commit description doesn't seem to match the patches at all.
I don't see any exporting happening here at all - this is documenting
The real
export code is in 2/6 patch, yes this is the document just
describe the exporting contents
the export. Maybe I am just misunderstanding, but this commit
message
just doesn't seem to match the change. Secondly, should the subject not
be something like "docs: admin-guide: add riscv crash kernel yada yada"?
the commit log for the file
'Documentation/admin-guide/kdump/vmcoreinfo.rst' is not unified in the
commit history of the file. I agree with you 'docs: admin-guide: xxx' is
better, will fix it V6.
Maybe the current subject lime that explains the lack of a review
from
the docs maintainer?
yes, it is possible :)
Thanks,
Conor.
For your comments for other patches, I will fix it in v6, thanks
> Signed-off-by: Xianting Tian <xianting.tian(a)linux.alibaba.com>
> ---
> .../admin-guide/kdump/vmcoreinfo.rst | 31 +++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst
b/Documentation/admin-guide/kdump/vmcoreinfo.rst
> index 8419019b6a88..6b76284a503c 100644
> --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
> +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
> @@ -595,3 +595,34 @@ X2TLB
> -----
>
> Indicates whether the crashed kernel enabled SH extended mode.
> +
> +RISCV64
> +=======
> +
> +VA_BITS
> +-------
> +
> +The maximum number of bits for virtual addresses. Used to compute the
> +virtual memory ranges.
> +
> +PAGE_OFFSET
> +-----------
> +
> +Indicates the virtual kernel start address of direct-mapped RAM region.
> +
> +phys_ram_base
> +-------------
> +
> +Indicates the start physical RAM address.
> +
> +MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END
> +-----------------------------------------------------------------------------
> +KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END
> +----------------------------------------------------------------------
> +
> +Used to get the correct ranges:
> + MODULES_VADDR ~ MODULES_END : Kernel module space.
> + VMALLOC_START ~ VMALLOC_END : vmalloc() / ioremap() space.
> + VMEMMAP_START ~ VMEMMAP_END : vmemmap region, used for struct page array.
> + KASAN_SHADOW_START ~ KASAN_SHADOW_END : kasan shadow space.
> + KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END : Kernel link and BPF space.
10:06 p.m.
New subject: [PATCH V5 5/6] riscv: crash_core: Export kernel vm layout, phys_ram_base
On Tue, Aug 02, 2022 at 08:18:17PM +0800, Xianting Tian wrote:
These infos are needed by the kdump crash tool. Since these values
change
from time to time, it is preferable to export them via vmcoreinfo than to
change the crash's code frequently.
I have to agree with Conor.Dooley, that this patch is misleading (I see
documentation instead of real export). So IMO, the patch subject should
be "Documentation: kdump: describe VMCOREINFO export for RISCV64".
For MODULES_VADDR and friends, the doc can be improved, like:
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst
b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index 6b76284a503ca5..6694acc32c3588 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -615,14 +615,13 @@ phys_ram_base
Indicates the start physical RAM address.
-MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END
------------------------------------------------------------------------------
-KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END
-----------------------------------------------------------------------
+MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END|KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END
+----------------------------------------------------------------------------------------------------------------------------------------------------
Used to get the correct ranges:
- MODULES_VADDR ~ MODULES_END : Kernel module space.
- VMALLOC_START ~ VMALLOC_END : vmalloc() / ioremap() space.
- VMEMMAP_START ~ VMEMMAP_END : vmemmap region, used for struct page array.
- KASAN_SHADOW_START ~ KASAN_SHADOW_END : kasan shadow space.
- KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END : Kernel link and BPF space.
+
+ * MODULES_VADDR ~ MODULES_END : Kernel module space.
+ * VMALLOC_START ~ VMALLOC_END : vmalloc() / ioremap() space.
+ * VMEMMAP_START ~ VMEMMAP_END : vmemmap region, used for struct page array.
+ * KASAN_SHADOW_START ~ KASAN_SHADOW_END : kasan shadow space.
+ * KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END : Kernel link and BPF space.
Thanks.
--
An old man doll... just what I always wanted! - Clara
10:37 p.m.
New subject: [PATCH V5 5/6] riscv: crash_core: Export kernel vm layout, phys_ram_base
在 2022/8/11 上午11:06, Bagas Sanjaya 写道:
On Tue, Aug 02, 2022 at 08:18:17PM +0800, Xianting Tian wrote:
> These infos are needed by the kdump crash tool. Since these values change
> from time to time, it is preferable to export them via vmcoreinfo than to
> change the crash's code frequently.
>
I have to agree with Conor.Dooley, that this patch is misleading (I see
documentation instead of real export). So IMO, the patch subject should
be "Documentation: kdump: describe VMCOREINFO export for RISCV64".
For MODULES_VADDR and friends, the doc can be improved, like:
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst
b/Documentation/admin-guide/kdump/vmcoreinfo.rst
index 6b76284a503ca5..6694acc32c3588 100644
--- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
+++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
@@ -615,14 +615,13 @@ phys_ram_base
Indicates the start physical RAM address.
-MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END
------------------------------------------------------------------------------
-KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END
-----------------------------------------------------------------------
+MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END|KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END
+----------------------------------------------------------------------------------------------------------------------------------------------------
Used to get the correct ranges:
- MODULES_VADDR ~ MODULES_END : Kernel module space.
- VMALLOC_START ~ VMALLOC_END : vmalloc() / ioremap() space.
- VMEMMAP_START ~ VMEMMAP_END : vmemmap region, used for struct page array.
- KASAN_SHADOW_START ~ KASAN_SHADOW_END : kasan shadow space.
- KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END : Kernel link and BPF space.
+
+ * MODULES_VADDR ~ MODULES_END : Kernel module space.
+ * VMALLOC_START ~ VMALLOC_END : vmalloc() / ioremap() space.
+ * VMEMMAP_START ~ VMEMMAP_END : vmemmap region, used for struct page array.
+ * KASAN_SHADOW_START ~ KASAN_SHADOW_END : kasan shadow space.
+ * KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END : Kernel link and BPF space.
Thanks for
the comment, I will fix it in V6
Thanks.
7:18 a.m.
New subject: [PATCH V5 6/6] RISC-V: Fixup schedule out issue in machine_crash_shutdown()
Fixup schedule out issue in machine_crash_shutdown(), which is triggered
by RCU Stall.
[224521.877268] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[224521.883471] rcu: 0-...0: (3 GPs behind) idle=cfa/0/0x1 softirq=3968793/3968793
fqs=2495
[224521.891742] (detected by 2, t=5255 jiffies, g=60855593, q=328)
[224521.897754] Task dump for CPU 0:
[224521.901074] task:swapper/0 state:R running task stack: 0 pid: 0 ppid:
0 flags:0x00000008
[224521.911090] Call Trace:
[224521.913638] [<ffffffe000c432de>] __schedule+0x208/0x5ea
[224521.918957] Kernel panic - not syncing: RCU Stall
[224521.923773] bad: scheduling from the idle thread!
[224521.928571] CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Tainted: G O
5.10.113-yocto-standard #1
[224521.938658] Call Trace:
[224521.941200] [<ffffffe00020395c>] walk_stackframe+0x0/0xaa
[224521.946689] [<ffffffe000c34f8e>] show_stack+0x32/0x3e
[224521.951830] [<ffffffe000c39020>] dump_stack_lvl+0x7e/0xa2
[224521.957317] [<ffffffe000c39058>] dump_stack+0x14/0x1c
[224521.962459] [<ffffffe000243884>] dequeue_task_idle+0x2c/0x40
[224521.968207] [<ffffffe000c434f4>] __schedule+0x41e/0x5ea
[224521.973520] [<ffffffe000c43826>] schedule+0x34/0xe4
[224521.978487] [<ffffffe000c46cae>] schedule_timeout+0xc6/0x170
[224521.984234] [<ffffffe000c4491e>] wait_for_completion+0x98/0xf2
[224521.990157] [<ffffffe00026d9e2>] __wait_rcu_gp+0x148/0x14a
[224521.995733] [<ffffffe0002761c4>] synchronize_rcu+0x5c/0x66
[224522.001307] [<ffffffe00026f1a6>] rcu_sync_enter+0x54/0xe6
[224522.006795] [<ffffffe00025a436>] percpu_down_write+0x32/0x11c
[224522.012629] [<ffffffe000c4266a>] _cpu_down+0x92/0x21a
[224522.017771] [<ffffffe000219a0a>] smp_shutdown_nonboot_cpus+0x90/0x118
[224522.024299] [<ffffffe00020701e>] machine_crash_shutdown+0x30/0x4a
[224522.030483] [<ffffffe00029a3f8>] __crash_kexec+0x62/0xa6
[224522.035884] [<ffffffe000c3515e>] panic+0xfa/0x2b6
[224522.040678] [<ffffffe0002772be>] rcu_sched_clock_irq+0xc26/0xcb8
[224522.046774] [<ffffffe00027fc7a>] update_process_times+0x62/0x8a
[224522.052785] [<ffffffe00028d522>] tick_sched_timer+0x9e/0x102
[224522.058533] [<ffffffe000280c3a>] __hrtimer_run_queues+0x16a/0x318
[224522.064716] [<ffffffe0002812ec>] hrtimer_interrupt+0xd4/0x228
[224522.070551] [<ffffffe0009a69b6>] riscv_timer_interrupt+0x3c/0x48
[224522.076646] [<ffffffe000268f8c>] handle_percpu_devid_irq+0xb0/0x24c
[224522.083004] [<ffffffe00026428e>] __handle_domain_irq+0xa8/0x122
[224522.089014] [<ffffffe00062f954>] riscv_intc_irq+0x38/0x60
[224522.094501] [<ffffffe000201bd4>] ret_from_exception+0x0/0xc
[224522.100161] [<ffffffe000c42146>] rcu_eqs_enter.constprop.0+0x8c/0xb8
With the patch, it can enter crash system when RCU Stall occur.
Signed-off-by: Xianting Tian <xianting.tian(a)linux.alibaba.com>
---
arch/riscv/kernel/machine_kexec.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/arch/riscv/kernel/machine_kexec.c b/arch/riscv/kernel/machine_kexec.c
index 86d1b5f9dfb5..ee79e6839b86 100644
--- a/arch/riscv/kernel/machine_kexec.c
+++ b/arch/riscv/kernel/machine_kexec.c
@@ -138,19 +138,37 @@ void machine_shutdown(void)
#endif
}
+/* Override the weak function in kernel/panic.c */
+void crash_smp_send_stop(void)
+{
+ static int cpus_stopped;
+
+ /*
+ * This function can be called twice in panic path, but obviously
+ * we execute this only once.
+ */
+ if (cpus_stopped)
+ return;
+
+ smp_send_stop();
+ cpus_stopped = 1;
+}
+
/*
* machine_crash_shutdown - Prepare to kexec after a kernel crash
*
* This function is called by crash_kexec just before machine_kexec
- * below and its goal is similar to machine_shutdown, but in case of
- * a kernel crash. Since we don't handle such cases yet, this function
- * is empty.
+ * and its goal is to shutdown non-crashing cpus and save registers.
*/
void
machine_crash_shutdown(struct pt_regs *regs)
{
+ local_irq_disable();
+
+ /* shutdown non-crashing cpus */
+ crash_smp_send_stop();
+
crash_save_cpu(regs, smp_processor_id());
- machine_shutdown();
pr_info("Starting crashdump kernel...\n");
}
--
2.17.1
4:20 p.m.
New subject: [PATCH V5 6/6] RISC-V: Fixup schedule out issue in machine_crash_shutdown()
On 02/08/2022 13:18, Xianting Tian wrote:
Fixup schedule out issue in machine_crash_shutdown(), which is
triggered
by RCU Stall.
[224521.877268] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[224521.883471] rcu: 0-...0: (3 GPs behind) idle=cfa/0/0x1 softirq=3968793/3968793
fqs=2495
[224521.891742] (detected by 2, t=5255 jiffies, g=60855593, q=328)
[224521.897754] Task dump for CPU 0:
[224521.901074] task:swapper/0 state:R running task stack: 0 pid: 0
ppid: 0 flags:0x00000008
[224521.911090] Call Trace:
[224521.913638] [<ffffffe000c432de>] __schedule+0x208/0x5ea
[224521.918957] Kernel panic - not syncing: RCU Stall
[224521.923773] bad: scheduling from the idle thread!
[224521.928571] CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Tainted: G O
5.10.113-yocto-standard #1
[224521.938658] Call Trace:
[224521.941200] [<ffffffe00020395c>] walk_stackframe+0x0/0xaa
[224521.946689] [<ffffffe000c34f8e>] show_stack+0x32/0x3e
[224521.951830] [<ffffffe000c39020>] dump_stack_lvl+0x7e/0xa2
[224521.957317] [<ffffffe000c39058>] dump_stack+0x14/0x1c
[224521.962459] [<ffffffe000243884>] dequeue_task_idle+0x2c/0x40
[224521.968207] [<ffffffe000c434f4>] __schedule+0x41e/0x5ea
[224521.973520] [<ffffffe000c43826>] schedule+0x34/0xe4
[224521.978487] [<ffffffe000c46cae>] schedule_timeout+0xc6/0x170
[224521.984234] [<ffffffe000c4491e>] wait_for_completion+0x98/0xf2
[224521.990157] [<ffffffe00026d9e2>] __wait_rcu_gp+0x148/0x14a
[224521.995733] [<ffffffe0002761c4>] synchronize_rcu+0x5c/0x66
[224522.001307] [<ffffffe00026f1a6>] rcu_sync_enter+0x54/0xe6
[224522.006795] [<ffffffe00025a436>] percpu_down_write+0x32/0x11c
[224522.012629] [<ffffffe000c4266a>] _cpu_down+0x92/0x21a
[224522.017771] [<ffffffe000219a0a>] smp_shutdown_nonboot_cpus+0x90/0x118
[224522.024299] [<ffffffe00020701e>] machine_crash_shutdown+0x30/0x4a
[224522.030483] [<ffffffe00029a3f8>] __crash_kexec+0x62/0xa6
[224522.035884] [<ffffffe000c3515e>] panic+0xfa/0x2b6
[224522.040678] [<ffffffe0002772be>] rcu_sched_clock_irq+0xc26/0xcb8
[224522.046774] [<ffffffe00027fc7a>] update_process_times+0x62/0x8a
[224522.052785] [<ffffffe00028d522>] tick_sched_timer+0x9e/0x102
[224522.058533] [<ffffffe000280c3a>] __hrtimer_run_queues+0x16a/0x318
[224522.064716] [<ffffffe0002812ec>] hrtimer_interrupt+0xd4/0x228
[224522.070551] [<ffffffe0009a69b6>] riscv_timer_interrupt+0x3c/0x48
[224522.076646] [<ffffffe000268f8c>] handle_percpu_devid_irq+0xb0/0x24c
[224522.083004] [<ffffffe00026428e>] __handle_domain_irq+0xa8/0x122
[224522.089014] [<ffffffe00062f954>] riscv_intc_irq+0x38/0x60
[224522.094501] [<ffffffe000201bd4>] ret_from_exception+0x0/0xc
[224522.100161] [<ffffffe000c42146>] rcu_eqs_enter.constprop.0+0x8c/0xb8
With the patch, it can enter crash system when RCU Stall occur.
Signed-off-by: Xianting Tian <xianting.tian(a)linux.alibaba.com>
Hmm, is there a Fixes: tag for this patch? Looks like a fix to me.
Could you also move it to the start of the patchset?
Thanks,
Conor.
---
arch/riscv/kernel/machine_kexec.c | 26 ++++++++++++++++++++++----
1 file changed, 22 insertions(+), 4 deletions(-)
diff --git a/arch/riscv/kernel/machine_kexec.c b/arch/riscv/kernel/machine_kexec.c
index 86d1b5f9dfb5..ee79e6839b86 100644
--- a/arch/riscv/kernel/machine_kexec.c
+++ b/arch/riscv/kernel/machine_kexec.c
@@ -138,19 +138,37 @@ void machine_shutdown(void)
#endif
}
+/* Override the weak function in kernel/panic.c */
+void crash_smp_send_stop(void)
+{
+ static int cpus_stopped;
+
+ /*
+ * This function can be called twice in panic path, but obviously
+ * we execute this only once.
+ */
+ if (cpus_stopped)
+ return;
+
+ smp_send_stop();
+ cpus_stopped = 1;
+}
+
/*
* machine_crash_shutdown - Prepare to kexec after a kernel crash
*
* This function is called by crash_kexec just before machine_kexec
- * below and its goal is similar to machine_shutdown, but in case of
- * a kernel crash. Since we don't handle such cases yet, this function
- * is empty.
+ * and its goal is to shutdown non-crashing cpus and save registers.
*/
void
machine_crash_shutdown(struct pt_regs *regs)
{
+ local_irq_disable();
+
+ /* shutdown non-crashing cpus */
+ crash_smp_send_stop();
+
crash_save_cpu(regs, smp_processor_id());
- machine_shutdown();
pr_info("Starting crashdump kernel...\n");
}
1:58 a.m.
Hi Palmer
Could you please help review this patch set? thanks.
Crash-utility patch set is ready(acked by HAGIO KAZUHITO), now waiting
the kernel patch set merged firstly.
在 2022/8/2 下午8:18, Xianting Tian 写道:
I ever sent the patch 1 in the link:
https://patchwork.kernel.org/project/linux-riscv/patch/20220708073150.352...
And patch 2,3 in the link:
https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367...
https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367...
This patch set just put these patches together, and with three new patch 4, 5, 6.
these six patches are the fixups for machine_kexec, kernel mode PC for vmcore
and improvements for vmcoreinfo, memory layout dump and fixup chedule out issue
in machine_crash_shutdown().
The main changes in the six patchs as below,
Patch 1: use __smp_processor_id() instead of smp_processor_id() to cleanup
the console prints.
Patch 2: Add VM layout, va bits, ram base to vmcoreinfo, which can simplify
the development of crash tool as ARM64 already did
(arch/arm64/kernel/crash_core.c).
Patch 3: Add modules to virtual kernel memory layout dump.
Patch 4: Fixup to get correct kernel mode PC for vmcore.
Patch 5: Updates vmcoreinfo.rst.
Patch 6: Fixup schedule out issue in machine_crash_shutdown()
With these six patches(patch 2 is must), crash tool can work well to analyze
a vmcore. The patches for crash tool for RISCV64 is in the link:
https://lore.kernel.org/linux-riscv/20220801043040.2003264-1-xianting.tia...
------
Changes v1 -> v2:
1, remove the patch "Add a fast call path of crash_kexec()" from this series
of patches, as it already applied to riscv git.
https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?h...
2, add 'Reviewed-by' based on the comments of v1.
Changes v2 -> v3:
use "riscv" instead of "riscv64" in patch 5 subject line.
Changes v3 -> v4:
use "riscv" instead of "riscv64" in the summary of patch 5 subject
line.
Changes v4 -> v5:
add a new patch "RISC-V: Fixup schedule out issue in
machine_crash_shutdown()"
Xianting Tian (6):
RISC-V: use __smp_processor_id() instead of smp_processor_id()
RISC-V: Add arch_crash_save_vmcoreinfo support
riscv: Add modules to virtual kernel memory layout dump
RISC-V: Fixup getting correct current pc
riscv: crash_core: Export kernel vm layout, phys_ram_base
RISC-V: Fixup schedule out issue in machine_crash_shutdown()
.../admin-guide/kdump/vmcoreinfo.rst | 31 +++++++++++++++++++
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/crash_core.c | 29 +++++++++++++++++
arch/riscv/kernel/crash_save_regs.S | 2 +-
arch/riscv/kernel/machine_kexec.c | 28 ++++++++++++++---
arch/riscv/mm/init.c | 4 +++
6 files changed, 89 insertions(+), 6 deletions(-)
create mode 100644 arch/riscv/kernel/crash_core.c
4:24 p.m.
On 09/08/2022 07:58, Xianting Tian wrote:
Hi Palmer
Could you please help review this patch set? thanks.
Hey Xianting,
Obviously I am not Palmer, but I left some comments on the
patchset. Sorry for the delay in getting back onto you on your
latest version, I got confused as to which versions I had reviewed.
Conor.
Crash-utility patch set is ready(acked by HAGIO KAZUHITO), now waiting the kernel patch
set merged firstly.
在 2022/8/2 下午8:18, Xianting Tian 写道:
> I ever sent the patch 1 in the link:
>
https://patchwork.kernel.org/project/linux-riscv/patch/20220708073150.352...
> And patch 2,3 in the link:
>
https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367...
>
https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367...
>
> This patch set just put these patches together, and with three new patch 4, 5, 6.
> these six patches are the fixups for machine_kexec, kernel mode PC for vmcore
> and improvements for vmcoreinfo, memory layout dump and fixup chedule out issue
> in machine_crash_shutdown().
>
> The main changes in the six patchs as below,
> Patch 1: use __smp_processor_id() instead of smp_processor_id() to cleanup
> the console prints.
> Patch 2: Add VM layout, va bits, ram base to vmcoreinfo, which can simplify
> the development of crash tool as ARM64 already did
> (arch/arm64/kernel/crash_core.c).
> Patch 3: Add modules to virtual kernel memory layout dump.
> Patch 4: Fixup to get correct kernel mode PC for vmcore.
> Patch 5: Updates vmcoreinfo.rst.
> Patch 6: Fixup schedule out issue in machine_crash_shutdown()
>
> With these six patches(patch 2 is must), crash tool can work well to analyze
> a vmcore. The patches for crash tool for RISCV64 is in the link:
>
https://lore.kernel.org/linux-riscv/20220801043040.2003264-1-xianting.tia...
>
> ------
> Changes v1 -> v2:
> 1, remove the patch "Add a fast call path of crash_kexec()" from this
series
> of patches, as it already applied to riscv git.
>
https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?h...
> 2, add 'Reviewed-by' based on the comments of v1.
> Changes v2 -> v3:
> use "riscv" instead of "riscv64" in patch 5 subject line.
> Changes v3 -> v4:
> use "riscv" instead of "riscv64" in the summary of patch 5
subject line.
> Changes v4 -> v5:
> add a new patch "RISC-V: Fixup schedule out issue in
machine_crash_shutdown()"
>
> Xianting Tian (6):
> RISC-V: use __smp_processor_id() instead of smp_processor_id()
> RISC-V: Add arch_crash_save_vmcoreinfo support
> riscv: Add modules to virtual kernel memory layout dump
> RISC-V: Fixup getting correct current pc
> riscv: crash_core: Export kernel vm layout, phys_ram_base
> RISC-V: Fixup schedule out issue in machine_crash_shutdown()
>
> .../admin-guide/kdump/vmcoreinfo.rst | 31 +++++++++++++++++++
> arch/riscv/kernel/Makefile | 1 +
> arch/riscv/kernel/crash_core.c | 29 +++++++++++++++++
> arch/riscv/kernel/crash_save_regs.S | 2 +-
> arch/riscv/kernel/machine_kexec.c | 28 ++++++++++++++---
> arch/riscv/mm/init.c | 4 +++
> 6 files changed, 89 insertions(+), 6 deletions(-)
> create mode 100644 arch/riscv/kernel/crash_core.c
>
9:54 p.m.
在 2022/8/10 上午5:24, Conor.Dooley(a)microchip.com 写道:
On 09/08/2022 07:58, Xianting Tian wrote:
> Hi Palmer
>
> Could you please help review this patch set? thanks.
Hey Xianting,
Obviously I am not Palmer, but I left some comments on the
patchset. Sorry for the delay in getting back onto you on your
latest version, I got confused as to which versions I had reviewed.
You ever reviewed this version patch set,
https://lore.kernel.org/lkml/20220725014539.1037627-1-xianting.tian@linux...
<https://lore.kernel.org/lkml/20220725014539.1037627-1-xianting.tian@linux...
Conor.
>
> Crash-utility patch set is ready(acked by HAGIO KAZUHITO), now waiting the kernel
patch set merged firstly.
>
> 在 2022/8/2 下午8:18, Xianting Tian 写道:
>> I ever sent the patch 1 in the link:
>>
https://patchwork.kernel.org/project/linux-riscv/patch/20220708073150.352...
>> And patch 2,3 in the link:
>>
https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367...
>>
https://patchwork.kernel.org/project/linux-riscv/patch/20220714113300.367...
>>
>> This patch set just put these patches together, and with three new patch 4, 5,
6.
>> these six patches are the fixups for machine_kexec, kernel mode PC for vmcore
>> and improvements for vmcoreinfo, memory layout dump and fixup chedule out issue
>> in machine_crash_shutdown().
>>
>> The main changes in the six patchs as below,
>> Patch 1: use __smp_processor_id() instead of smp_processor_id() to cleanup
>> the console prints.
>> Patch 2: Add VM layout, va bits, ram base to vmcoreinfo, which can simplify
>> the development of crash tool as ARM64 already did
>> (arch/arm64/kernel/crash_core.c).
>> Patch 3: Add modules to virtual kernel memory layout dump.
>> Patch 4: Fixup to get correct kernel mode PC for vmcore.
>> Patch 5: Updates vmcoreinfo.rst.
>> Patch 6: Fixup schedule out issue in machine_crash_shutdown()
>>
>> With these six patches(patch 2 is must), crash tool can work well to analyze
>> a vmcore. The patches for crash tool for RISCV64 is in the link:
>>
https://lore.kernel.org/linux-riscv/20220801043040.2003264-1-xianting.tia...
>>
>> ------
>> Changes v1 -> v2:
>> 1, remove the patch "Add a fast call path of crash_kexec()" from
this series
>> of patches, as it already applied to riscv git.
>>
https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?h...
>> 2, add 'Reviewed-by' based on the comments of v1.
>> Changes v2 -> v3:
>> use "riscv" instead of "riscv64" in patch 5 subject line.
>> Changes v3 -> v4:
>> use "riscv" instead of "riscv64" in the summary of patch 5
subject line.
>> Changes v4 -> v5:
>> add a new patch "RISC-V: Fixup schedule out issue in
machine_crash_shutdown()"
>>
>> Xianting Tian (6):
>> RISC-V: use __smp_processor_id() instead of smp_processor_id()
>> RISC-V: Add arch_crash_save_vmcoreinfo support
>> riscv: Add modules to virtual kernel memory layout dump
>> RISC-V: Fixup getting correct current pc
>> riscv: crash_core: Export kernel vm layout, phys_ram_base
>> RISC-V: Fixup schedule out issue in machine_crash_shutdown()
>>
>> .../admin-guide/kdump/vmcoreinfo.rst | 31 +++++++++++++++++++
>> arch/riscv/kernel/Makefile | 1 +
>> arch/riscv/kernel/crash_core.c | 29 +++++++++++++++++
>> arch/riscv/kernel/crash_save_regs.S | 2 +-
>> arch/riscv/kernel/machine_kexec.c | 28 ++++++++++++++---
>> arch/riscv/mm/init.c | 4 +++
>> 6 files changed, 89 insertions(+), 6 deletions(-)
>> create mode 100644 arch/riscv/kernel/crash_core.c
>>
838
days inactive
847
days old
devel@lists.crash-utility.osci.io
17 comments
3 participants
participants (3)
-
Bagas Sanjaya -
Conor.Dooley＠microchip.com -
Xianting Tian