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 <[email protected]>
---
.../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 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.
--
2.17.1
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.
--
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.
--
An old man doll... just what I always wanted! - Clara
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
在 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.
>