[Crash-utility] [PATCH V3 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
lijiang
lijiang at redhat.com
Wed Oct 19 02:49:46 UTC 2022
On Wed, Oct 19, 2022 at 9:50 AM Xianting Tian <
xianting.tian at linux.alibaba.com> wrote:
>
> 在 2022/10/18 下午6:03, Baoquan He 写道:
> > On 10/18/22 at 05:25pm, Xianting Tian wrote:
> >> 在 2022/10/18 下午5:10, Baoquan He 写道:
> >>> On 10/18/22 at 04:17pm, Xianting Tian wrote:
> >>>> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES,
> VMALLOC,
> >>>> VMEMMAP and KERNEL_LINK_ADDR ranges), va bits and ram base for vmcore.
> >>>>
> >>>> Default pagetable levels and PAGE_OFFSET aren't same for different
> kernel
> >>>> version as below. For pagetable levels, it sets sv57 by default and
> falls
> >>>> back to setting sv48 at boot time if sv57 is not supported by the
> hardware.
> >>>>
> >>>> For ram base, the default value is 0x80200000 for qemu riscv64 env
> and,
> >>>> for example, is 0x200000 on the 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 at 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 db6e4b1294ba..4cf303a779ab 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);
> >>> Seems this is the firsr ARCH where kasan and kernel link/bpf space are
> >>> added to dump and analyze. Just curious, have you got code change to
> >>> make use of them to do dumping and analyze?
> >> KASAN_SHADOW_START is not used, KERNEL_LINK_ADDR is used in the crash
> patch set:
> >>
> https://patchwork.kernel.org/project/linux-riscv/cover/20220813031753.3097720-1-xianting.tian@linux.alibaba.com/
> > Oh, I would say please no. Sometime we got tons of objection when adding
> an
> > necessary one, we definitely should not add one for possible future
> > use.
> >
> > For this kind of newly added one, we need get ack from
> > makedumpfile/crash utility maintainer so that we know they are necessary
> > to have. At least they don't oppose.
>
> Hi Kazu, Li Jiang
>
> Could you help comment whether we need KASAN_SHADOW_START and
> KERNEL_LINK_ADDR area export for vmcore from crash point of view？
>
>
Thank you for the information, Baoquan and Xianting.
As you mentioned, the symbol is not currently used in userspace debugging
tools. If this symbol may be used in the future, export it at that time.
> In my crash patch set, I don't use KASAN_SHADOW_START,
> And only get the value of KERNEL_LINK_ADDR, not realy use it.
>
Can you help confirm that the KERNEL_LINK_ADDR is not used in your crash
patchset? I see it was used in VTOP(). Otherwise, you may need to improve
the crash patchset.
+#define VTOP(X) ({
\
+ ulong _X = X;
\
+ (THIS_KERNEL_VERSION >= LINUX(5,13,0) &&
\
+ (_X) >= machdep->machspec->kernel_link_addr) ?
\
+ (((unsigned
long)(_X)-(machdep->machspec->kernel_link_addr)) + \
+ machdep->machspec->phys_base):
\
+ (((unsigned long)(_X)-(machdep->kvbase)) +
\
+ machdep->machspec->phys_base);
\
+ })
Thanks.
Lianbo
https://patchwork.kernel.org/project/linux-riscv/cover/20220813031753.3097720-1-xianting.tian@linux.alibaba.com/
>
> If we need to remove the two areas, I will resend the crash patch set and
> kernel patch set.
> thanks
>
> >
> >> I add it in case of using in furture.
> >>
> >>> Thanks
> >>> Baoquan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20221019/65e24639/attachment-0001.htm>
More information about the Crash-utility
mailing list