<div dir="ltr"><div dir="ltr">On Wed, Oct 19, 2022 at 9:50 AM Xianting Tian <<a href="mailto:xianting.tian@linux.alibaba.com">xianting.tian@linux.alibaba.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
在 2022/10/18 下午6:03, Baoquan He 写道:<br>
> On 10/18/22 at 05:25pm, Xianting Tian wrote:<br>
>> 在 2022/10/18 下午5:10, Baoquan He 写道:<br>
>>> On 10/18/22 at 04:17pm, Xianting Tian wrote:<br>
>>>> Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC,<br>
>>>> VMEMMAP and KERNEL_LINK_ADDR ranges), va bits and ram base for vmcore.<br>
>>>><br>
>>>> Default pagetable levels and PAGE_OFFSET aren't same for different kernel<br>
>>>> version as below. For pagetable levels, it sets sv57 by default and falls<br>
>>>> back to setting sv48 at boot time if sv57 is not supported by the hardware.<br>
>>>><br>
>>>> For ram base, the default value is 0x80200000 for qemu riscv64 env and,<br>
>>>> for example, is 0x200000 on the XuanTie 910 CPU.<br>
>>>><br>
>>>>    * Linux Kernel 5.18 ~<br>
>>>>    *      PGTABLE_LEVELS = 5<br>
>>>>    *      PAGE_OFFSET = 0xff60000000000000<br>
>>>>    * Linux Kernel 5.17 ~<br>
>>>>    *      PGTABLE_LEVELS = 4<br>
>>>>    *      PAGE_OFFSET = 0xffffaf8000000000<br>
>>>>    * Linux Kernel 4.19 ~<br>
>>>>    *      PGTABLE_LEVELS = 3<br>
>>>>    *      PAGE_OFFSET = 0xffffffe000000000<br>
>>>><br>
>>>> Since these configurations change from time to time and version to version,<br>
>>>> it is preferable to export them via vmcoreinfo than to change the crash's<br>
>>>> code frequently, it can simplify the development of crash tool.<br>
>>>><br>
>>>> Signed-off-by: Xianting Tian <<a href="mailto:xianting.tian@linux.alibaba.com" target="_blank">xianting.tian@linux.alibaba.com</a>><br>
>>>> ---<br>
>>>>    arch/riscv/kernel/Makefile     |  1 +<br>
>>>>    arch/riscv/kernel/crash_core.c | 29 +++++++++++++++++++++++++++++<br>
>>>>    2 files changed, 30 insertions(+)<br>
>>>>    create mode 100644 arch/riscv/kernel/crash_core.c<br>
>>>><br>
>>>> diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile<br>
>>>> index db6e4b1294ba..4cf303a779ab 100644<br>
>>>> --- a/arch/riscv/kernel/Makefile<br>
>>>> +++ b/arch/riscv/kernel/Makefile<br>
>>>> @@ -81,6 +81,7 @@ obj-$(CONFIG_KGDB)               += kgdb.o<br>
>>>>    obj-$(CONFIG_KEXEC_CORE)        += kexec_relocate.o crash_save_regs.o machine_kexec.o<br>
>>>>    obj-$(CONFIG_KEXEC_FILE)        += elf_kexec.o machine_kexec_file.o<br>
>>>>    obj-$(CONFIG_CRASH_DUMP)        += crash_dump.o<br>
>>>> +obj-$(CONFIG_CRASH_CORE)  += crash_core.o<br>
>>>>    obj-$(CONFIG_JUMP_LABEL)        += jump_label.o<br>
>>>> diff --git a/arch/riscv/kernel/crash_core.c b/arch/riscv/kernel/crash_core.c<br>
>>>> new file mode 100644<br>
>>>> index 000000000000..8d7f5ff108da<br>
>>>> --- /dev/null<br>
>>>> +++ b/arch/riscv/kernel/crash_core.c<br>
>>>> @@ -0,0 +1,29 @@<br>
>>>> +// SPDX-License-Identifier: GPL-2.0-only<br>
>>>> +<br>
>>>> +#include <linux/crash_core.h><br>
>>>> +#include <linux/pagemap.h><br>
>>>> +<br>
>>>> +void arch_crash_save_vmcoreinfo(void)<br>
>>>> +{<br>
>>>> +  VMCOREINFO_NUMBER(VA_BITS);<br>
>>>> +  VMCOREINFO_NUMBER(phys_ram_base);<br>
>>>> +<br>
>>>> +  vmcoreinfo_append_str("NUMBER(PAGE_OFFSET)=0x%lx\n", PAGE_OFFSET);<br>
>>>> +  vmcoreinfo_append_str("NUMBER(VMALLOC_START)=0x%lx\n", VMALLOC_START);<br>
>>>> +  vmcoreinfo_append_str("NUMBER(VMALLOC_END)=0x%lx\n", VMALLOC_END);<br>
>>>> +  vmcoreinfo_append_str("NUMBER(VMEMMAP_START)=0x%lx\n", VMEMMAP_START);<br>
>>>> +  vmcoreinfo_append_str("NUMBER(VMEMMAP_END)=0x%lx\n", VMEMMAP_END);<br>
>>>> +#ifdef CONFIG_64BIT<br>
>>>> +  vmcoreinfo_append_str("NUMBER(MODULES_VADDR)=0x%lx\n", MODULES_VADDR);<br>
>>>> +  vmcoreinfo_append_str("NUMBER(MODULES_END)=0x%lx\n", MODULES_END);<br>
>>>> +#endif<br>
>>>> +<br>
>>>> +  if (IS_ENABLED(CONFIG_64BIT)) {<br>
>>>> +#ifdef CONFIG_KASAN<br>
>>>> +          vmcoreinfo_append_str("NUMBER(KASAN_SHADOW_START)=0x%lx\n", KASAN_SHADOW_START);<br>
>>>> +          vmcoreinfo_append_str("NUMBER(KASAN_SHADOW_END)=0x%lx\n", KASAN_SHADOW_END);<br>
>>>> +#endif<br>
>>>> +          vmcoreinfo_append_str("NUMBER(KERNEL_LINK_ADDR)=0x%lx\n", KERNEL_LINK_ADDR);<br>
>>>> +          vmcoreinfo_append_str("NUMBER(ADDRESS_SPACE_END)=0x%lx\n", ADDRESS_SPACE_END);<br>
>>> Seems this is the firsr ARCH where kasan and kernel link/bpf space are<br>
>>> added to dump and analyze. Just curious, have you got code change to<br>
>>> make use of them to do dumping and analyze?<br>
>> KASAN_SHADOW_START is not used, KERNEL_LINK_ADDR is used in the crash patch set:<br>
>> <a href="https://patchwork.kernel.org/project/linux-riscv/cover/20220813031753.3097720-1-xianting.tian@linux.alibaba.com/" rel="noreferrer" target="_blank">https://patchwork.kernel.org/project/linux-riscv/cover/20220813031753.3097720-1-xianting.tian@linux.alibaba.com/</a><br>
> Oh, I would say please no. Sometime we got tons of objection when adding an<br>
> necessary one, we definitely should not add one for possible future<br>
> use.<br>
><br>
> For this kind of newly added one, we need get ack from<br>
> makedumpfile/crash utility maintainer so that we know they are necessary<br>
> to have. At least they don't oppose.<br>
<br>
Hi Kazu, Li Jiang<br>
<br>
Could you help comment whether we need KASAN_SHADOW_START and <br>
KERNEL_LINK_ADDR area export for vmcore from crash point of view?<br>
<br></blockquote><div><br></div><div>Thank you for the information, Baoquan and Xianting.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In my crash patch set, I don't use KASAN_SHADOW_START,<br>
And only get the value of KERNEL_LINK_ADDR, not realy use it.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>+#define VTOP(X) ({                                                                     \<br>+       ulong _X = X;                                                                   \<br>+       (THIS_KERNEL_VERSION >= LINUX(5,13,0) &&                                        \<br>+               (_X) >= machdep->machspec->kernel_link_addr) ?                          \<br>+               (((unsigned long)(_X)-(machdep->machspec->kernel_link_addr)) +          \<br>+                machdep->machspec->phys_base):                                         \<br>+               (((unsigned long)(_X)-(machdep->kvbase)) +                              \<br>+                machdep->machspec->phys_base);                                         \<br>+       })<br></div><div><br></div><div>Thanks.</div><div>Lianbo</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<a href="https://patchwork.kernel.org/project/linux-riscv/cover/20220813031753.3097720-1-xianting.tian@linux.alibaba.com/" rel="noreferrer" target="_blank">https://patchwork.kernel.org/project/linux-riscv/cover/20220813031753.3097720-1-xianting.tian@linux.alibaba.com/</a><br>
<br>
If we need to remove the two areas, I will resend the crash patch set and kernel patch set.<br>
thanks<br>
<br>
><br>
>> I add it in case of using in furture.<br>
>><br>
>>> Thanks<br>
>>> Baoquan<br>
<br>
</blockquote></div></div>