| Message ID | 20221014074810.4471-3-xianting.tian@linux.alibaba.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Support VMCOREINFO export for RISCV64 | expand |
On Fri, Oct 14, 2022 at 03:48:10PM +0800, Xianting Tian wrote: > The following interrelated definitions and ranges are needed by the kdump > crash tool, they are exported by "arch/riscv/kernel/crash_core.c": > VA_BITS, > PAGE_OFFSET, > phys_ram_base, > MODULES_VADDR ~ MODULES_END, > VMALLOC_START ~ VMALLOC_END, > VMEMMAP_START ~ VMEMMAP_END, > KASAN_SHADOW_START ~ KASAN_SHADOW_END, > KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END > > Document these RISCV64 exports above. > The patch description LGTM, thanks. > +---------------------------------------------------------------------------------------------------------------------------------------------------- > +MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END|KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END > +---------------------------------------------------------------------------------------------------------------------------------------------------- The overline above header text is unnecessary, so I have to strip it: ---- >8 ---- diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst index 6c7a1728de220e..8e2e164cf3db49 100644 --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst @@ -615,7 +615,6 @@ 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 ---------------------------------------------------------------------------------------------------------------------------------------------------- Thanks.
Hey Bagas, On Fri, Oct 14, 2022 at 08:01:32PM +0700, Bagas Sanjaya wrote: > On Fri, Oct 14, 2022 at 03:48:10PM +0800, Xianting Tian wrote: > > The following interrelated definitions and ranges are needed by the kdump > > crash tool, they are exported by "arch/riscv/kernel/crash_core.c": > > VA_BITS, > > PAGE_OFFSET, > > phys_ram_base, > > MODULES_VADDR ~ MODULES_END, > > VMALLOC_START ~ VMALLOC_END, > > VMEMMAP_START ~ VMEMMAP_END, > > KASAN_SHADOW_START ~ KASAN_SHADOW_END, > > KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END > > > > Document these RISCV64 exports above. > > > > The patch description LGTM, thanks. > > > +---------------------------------------------------------------------------------------------------------------------------------------------------- > > +MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END|KASAN_SHADOW_START|KASAN_SHADOW_END|KERNEL_LINK_ADDR|ADDRESS_SPACE_END > > +---------------------------------------------------------------------------------------------------------------------------------------------------- > > The overline above header text is unnecessary, so I have to strip it: > > ---- >8 ---- > > diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst > index 6c7a1728de220e..8e2e164cf3db49 100644 > --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst > +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst > @@ -615,7 +615,6 @@ 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 > ---------------------------------------------------------------------------------------------------------------------------------------------------- Without whitespace highlighting, your change threw me for a sec.. But yeah, having the overline is inconsistent with other headings in the doc. What I wanted to ask about was the linelength as I don't know anything about rst. Is it possible to avoid having the ~150 character line or is that a necessary evil? Thanks, Conor. > > Thanks. > > -- > An old man doll... just what I always wanted! - Clara
On 10/14/22 20:10, Conor Dooley wrote: > Without whitespace highlighting, your change threw me for a sec.. But > yeah, having the overline is inconsistent with other headings in the > doc. > > What I wanted to ask about was the linelength as I don't know anything > about rst. Is it possible to avoid having the ~150 character line or is > that a necessary evil? > I think the section describes correct range exports; however since there are many such ranges with distinct purposes, it is better to split the section into multiple sections describing each range. If we go without splitting, the 150-character header is necessary (I don't know how to split the header text line without trigger any warnings). Thanks.
在 2022/10/14 下午9:23, Bagas Sanjaya 写道: > On 10/14/22 20:10, Conor Dooley wrote: >> Without whitespace highlighting, your change threw me for a sec.. But >> yeah, having the overline is inconsistent with other headings in the >> doc. >> >> What I wanted to ask about was the linelength as I don't know anything >> about rst. Is it possible to avoid having the ~150 character line or is >> that a necessary evil? >> > I think the section describes correct range exports; however since there > are many such ranges with distinct purposes, it is better to split the > section into multiple sections describing each range. > > If we go without splitting, the 150-character header is necessary (I don't > know how to split the header text line without trigger any warnings). thanks, I send V2 patch, please help review. https://lkml.org/lkml/2022/10/14/447 > > Thanks. >
diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst index 6726f439958c..6c7a1728de22 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.
The following interrelated definitions and ranges are needed by the kdump crash tool, they are exported by "arch/riscv/kernel/crash_core.c": VA_BITS, PAGE_OFFSET, phys_ram_base, MODULES_VADDR ~ MODULES_END, VMALLOC_START ~ VMALLOC_END, VMEMMAP_START ~ VMEMMAP_END, KASAN_SHADOW_START ~ KASAN_SHADOW_END, KERNEL_LINK_ADDR ~ ADDRESS_SPACE_END Document these RISCV64 exports above. Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> --- .../admin-guide/kdump/vmcoreinfo.rst | 31 +++++++++++++++++++ 1 file changed, 31 insertions(+)