This patch series are the improvements for vmcoreinfo and memory
layout dump.
The first patch(1/2) is to add VM layout to vmcoreinfo, which can
simlify the development of crash tool as ARM64 already did
(arch/arm64/kernel/crash_core.c).
The second patch(2/2) is to add MODULES to memory layout dump.
Changes v1 -> v2:
patch 1: add VA_BITS to vmcoreinfo as ARM64 does, not satp_mode.
crash tool can read VA_BITS to determin the pagetable
levels.
patch 1,2: As MODULES area is only defined when CONFIG_64BIT=y for
riscv64, so only use MODULES area when CONFIG_64BIT=y.
Xianting Tian (2):
RISC-V: Add arch_crash_save_vmcoreinfo support
riscv: Add modules to virtual kernel memory layout dump
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/crash_core.c | 28 ++++++++++++++++++++++++++++
arch/riscv/mm/init.c | 3 +++
3 files changed, 32 insertions(+)
create mode 100644 arch/riscv/kernel/crash_core.c
--
2.17.1
Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,
VMEMMAP and KERNEL_LINK_ADDR ranges), satp mode 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 <[email protected]>
---
arch/riscv/kernel/Makefile | 1 +
arch/riscv/kernel/crash_core.c | 28 ++++++++++++++++++++++++++++
2 files changed, 29 insertions(+)
create mode 100644 arch/riscv/kernel/crash_core.c
diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
index c71d6591d539..54e4183db080 100644
--- a/arch/riscv/kernel/Makefile
+++ b/arch/riscv/kernel/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB) += kgdb.o
obj-$(CONFIG_KEXEC) += 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..c096904dd0f3
--- /dev/null
+++ b/arch/riscv/kernel/crash_core.c
@@ -0,0 +1,28 @@
+// 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);
+
+ /* Please note VMCOREINFO_NUMBER() uses "%d", not "%x" */
+ 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);
+
+ if (IS_ENABLED(CONFIG_64BIT)) {
+ vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
+ vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
+#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
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.
eg,
MODULES_VADDR - MODULES_END
0xffffffff01133000 - 0xffffffff80000000
Signed-off-by: Xianting Tian <[email protected]>
---
arch/riscv/mm/init.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index d466ec670e1f..bbc9431e9042 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -135,6 +135,9 @@ static void __init print_vm_layout(void)
(unsigned long)VMEMMAP_END);
print_ml("vmalloc", (unsigned long)VMALLOC_START,
(unsigned long)VMALLOC_END);
+ if (IS_ENABLED(CONFIG_64BIT))
+ print_ml("modules", (unsigned long)MODULES_VADDR,
+ (unsigned long)MODULES_END);
print_ml("lowmem", (unsigned long)PAGE_OFFSET,
(unsigned long)high_memory);
if (IS_ENABLED(CONFIG_64BIT)) {
--
2.17.1
On Thu, Jul 14, 2022 at 4:59 AM Xianting Tian
<[email protected]> wrote:
>
> As MODULES is only defined for CONFIG_64BIT, so we dump it when
> CONFIG_64BIT.
Doesn't this cause a compile-time error on 32-bit?
> (unsigned long)VMEMMAP_END);
> print_ml("vmalloc", (unsigned long)VMALLOC_START,
> (unsigned long)VMALLOC_END);
> + if (IS_ENABLED(CONFIG_64BIT))
> + print_ml("modules", (unsigned long)MODULES_VADDR,
> + (unsigned long)MODULES_END);
The IS_ENABLED() check prevents the line from getting executed, but
unlike an #ifdef it still relies on it to be parsable.
Arnd
在 2022/7/14 下午4:24, Arnd Bergmann 写道:
> On Thu, Jul 14, 2022 at 4:59 AM Xianting Tian
> <[email protected]> wrote:
>> As MODULES is only defined for CONFIG_64BIT, so we dump it when
>> CONFIG_64BIT.
> Doesn't this cause a compile-time error on 32-bit?
I tested, rv32 compile is OK.
>
>> (unsigned long)VMEMMAP_END);
>> print_ml("vmalloc", (unsigned long)VMALLOC_START,
>> (unsigned long)VMALLOC_END);
>> + if (IS_ENABLED(CONFIG_64BIT))
>> + print_ml("modules", (unsigned long)MODULES_VADDR,
>> + (unsigned long)MODULES_END);
> The IS_ENABLED() check prevents the line from getting executed, but
> unlike an #ifdef it still relies on it to be parsable.
Thanks, I will use #ifdef instead of IS_ENABLED
>
> Arnd
Am Donnerstag, 14. Juli 2022, 11:17:26 CEST schrieb Xianting Tian:
>
> 在 2022/7/14 下午4:24, Arnd Bergmann 写道:
> > On Thu, Jul 14, 2022 at 4:59 AM Xianting Tian
> > <[email protected]> wrote:
> >> As MODULES is only defined for CONFIG_64BIT, so we dump it when
> >> CONFIG_64BIT.
> > Doesn't this cause a compile-time error on 32-bit?
> I tested, rv32 compile is OK.
> >> (unsigned long)VMEMMAP_END);
> >> print_ml("vmalloc", (unsigned long)VMALLOC_START,
> >> (unsigned long)VMALLOC_END);
> >> + if (IS_ENABLED(CONFIG_64BIT))
> >> + print_ml("modules", (unsigned long)MODULES_VADDR,
> >> + (unsigned long)MODULES_END);
> > The IS_ENABLED() check prevents the line from getting executed, but
> > unlike an #ifdef it still relies on it to be parsable.
> Thanks, I will use #ifdef instead of IS_ENABLED
Patch1 also has that issue with the
if (IS_ENABLED(CONFIG_64BIT)) {
vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
....
module_alloc falls back to a weak variant [0] which is the same as the riscv variant
only then using VMALLOC_START - VMALLOC_END as range, as the riscv-variant
conditional to CONFIG_64BIT.
I'm wondering if it wouldn't be easier in the long run to just define
MODULES_VADDR, MODULES_END for 32bit to use these values and get rid of
the CONFIG_64BIT ifdef we already have for MODULES (and new ones we are
introducing now).
Heiko
[0] https://elixir.bootlin.com/linux/latest/source/kernel/module.c#L2835
在 2022/7/14 下午5:46, Heiko Stübner 写道:
> Am Donnerstag, 14. Juli 2022, 11:17:26 CEST schrieb Xianting Tian:
>> 在 2022/7/14 下午4:24, Arnd Bergmann 写道:
>>> On Thu, Jul 14, 2022 at 4:59 AM Xianting Tian
>>> <[email protected]> wrote:
>>>> As MODULES is only defined for CONFIG_64BIT, so we dump it when
>>>> CONFIG_64BIT.
>>> Doesn't this cause a compile-time error on 32-bit?
>> I tested, rv32 compile is OK.
>>>> (unsigned long)VMEMMAP_END);
>>>> print_ml("vmalloc", (unsigned long)VMALLOC_START,
>>>> (unsigned long)VMALLOC_END);
>>>> + if (IS_ENABLED(CONFIG_64BIT))
>>>> + print_ml("modules", (unsigned long)MODULES_VADDR,
>>>> + (unsigned long)MODULES_END);
>>> The IS_ENABLED() check prevents the line from getting executed, but
>>> unlike an #ifdef it still relies on it to be parsable.
>> Thanks, I will use #ifdef instead of IS_ENABLED
> Patch1 also has that issue with the
thanks, I will modify it in V3.
>
> if (IS_ENABLED(CONFIG_64BIT)) {
> vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);
> vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);
> ....
>
>
> module_alloc falls back to a weak variant [0] which is the same as the riscv variant
> only then using VMALLOC_START - VMALLOC_END as range, as the riscv-variant
> conditional to CONFIG_64BIT.
yes, I ever checked, actually before 5.13, it doesn't define MODULES
area but use VMALLOC for modules,
crash> mod
MODULE NAME BASE SIZE OBJECT FILE
ffffffdf8167f280 galcore ffffffdf81646000 3075841 (not loaded)
[CONFIG_KALLSYMS]
[ 0.000000] vmalloc : 0xffffffd000000000 - 0xffffffdfffffffff
(65535 MB)
>
> I'm wondering if it wouldn't be easier in the long run to just define
> MODULES_VADDR, MODULES_END for 32bit to use these values and get rid of
> the CONFIG_64BIT ifdef we already have for MODULES (and new ones we are
> introducing now).
>
>
> Heiko
>
>
> [0] https://elixir.bootlin.com/linux/latest/source/kernel/module.c#L2835
>
>