All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH V2 0/2] Improve vmcoreinfo and memory layout dump
@ 2022-07-14  2:58 ` Xianting Tian
  0 siblings, 0 replies; 14+ messages in thread
From: Xianting Tian @ 2022-07-14  2:58 UTC (permalink / raw)
  To: paul.walmsley, palmer, aou, alexandre.ghiti, guoren, anup, mick,
	rppt, heiko
  Cc: linux-riscv, linux-kernel, huanyi.xj, Xianting Tian

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


^ permalink raw reply	[flat|nested] 14+ messages in thread
* [PATCH V2 0/2] Improve vmcoreinfo and memory layout dump
@ 2022-07-14  2:58 ` Xianting Tian
  0 siblings, 0 replies; 14+ messages in thread
From: Xianting Tian @ 2022-07-14  2:58 UTC (permalink / raw)
  To: paul.walmsley, palmer, aou, alexandre.ghiti, guoren, anup, mick,
	rppt, heiko
  Cc: linux-riscv, linux-kernel, huanyi.xj, Xianting Tian

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


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 14+ messages in thread
* [PATCH V2 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
  2022-07-14  2:58 ` Xianting Tian
@ 2022-07-14  2:59   ` Xianting Tian
  -1 siblings, 0 replies; 14+ messages in thread
From: Xianting Tian @ 2022-07-14  2:59 UTC (permalink / raw)
  To: paul.walmsley, palmer, aou, alexandre.ghiti, guoren, anup, mick,
	rppt, heiko
  Cc: linux-riscv, linux-kernel, huanyi.xj, Xianting Tian

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 <xianting.tian@linux.alibaba.com>
---
 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


^ permalink raw reply related	[flat|nested] 14+ messages in thread
* [PATCH V2 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support
@ 2022-07-14  2:59   ` Xianting Tian
  0 siblings, 0 replies; 14+ messages in thread
From: Xianting Tian @ 2022-07-14  2:59 UTC (permalink / raw)
  To: paul.walmsley, palmer, aou, alexandre.ghiti, guoren, anup, mick,
	rppt, heiko
  Cc: linux-riscv, linux-kernel, huanyi.xj, Xianting Tian

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 <xianting.tian@linux.alibaba.com>
---
 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


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 14+ messages in thread
* [PATCH V2 2/2] riscv: Add modules to virtual kernel memory layout dump
  2022-07-14  2:58 ` Xianting Tian
@ 2022-07-14  2:59   ` Xianting Tian
  -1 siblings, 0 replies; 14+ messages in thread
From: Xianting Tian @ 2022-07-14  2:59 UTC (permalink / raw)
  To: paul.walmsley, palmer, aou, alexandre.ghiti, guoren, anup, mick,
	rppt, heiko
  Cc: linux-riscv, linux-kernel, huanyi.xj, Xianting Tian

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 <xianting.tian@linux.alibaba.com>
---
 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


^ permalink raw reply related	[flat|nested] 14+ messages in thread
* [PATCH V2 2/2] riscv: Add modules to virtual kernel memory layout dump
@ 2022-07-14  2:59   ` Xianting Tian
  0 siblings, 0 replies; 14+ messages in thread
From: Xianting Tian @ 2022-07-14  2:59 UTC (permalink / raw)
  To: paul.walmsley, palmer, aou, alexandre.ghiti, guoren, anup, mick,
	rppt, heiko
  Cc: linux-riscv, linux-kernel, huanyi.xj, Xianting Tian

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 <xianting.tian@linux.alibaba.com>
---
 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


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply related	[flat|nested] 14+ messages in thread
* Re: [PATCH V2 2/2] riscv: Add modules to virtual kernel memory layout dump
  2022-07-14  2:59   ` Xianting Tian
@ 2022-07-14  8:24     ` Arnd Bergmann
  -1 siblings, 0 replies; 14+ messages in thread
From: Arnd Bergmann @ 2022-07-14  8:24 UTC (permalink / raw)
  To: Xianting Tian
  Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
	Guo Ren, Anup Patel, Nick Kossifidis, Mike Rapoport,
	Heiko Stuebner, linux-riscv, Linux Kernel Mailing List,
	huanyi.xj

On Thu, Jul 14, 2022 at 4:59 AM Xianting Tian
<xianting.tian@linux.alibaba.com> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH V2 2/2] riscv: Add modules to virtual kernel memory layout dump
@ 2022-07-14  8:24     ` Arnd Bergmann
  0 siblings, 0 replies; 14+ messages in thread
From: Arnd Bergmann @ 2022-07-14  8:24 UTC (permalink / raw)
  To: Xianting Tian
  Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
	Guo Ren, Anup Patel, Nick Kossifidis, Mike Rapoport,
	Heiko Stuebner, linux-riscv, Linux Kernel Mailing List,
	huanyi.xj

On Thu, Jul 14, 2022 at 4:59 AM Xianting Tian
<xianting.tian@linux.alibaba.com> 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

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH V2 2/2] riscv: Add modules to virtual kernel memory layout dump
  2022-07-14  8:24     ` Arnd Bergmann
@ 2022-07-14  9:17       ` Xianting Tian
  -1 siblings, 0 replies; 14+ messages in thread
From: Xianting Tian @ 2022-07-14  9:17 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
	Guo Ren, Anup Patel, Nick Kossifidis, Mike Rapoport,
	Heiko Stuebner, linux-riscv, Linux Kernel Mailing List,
	huanyi.xj


在 2022/7/14 下午4:24, Arnd Bergmann 写道:
> On Thu, Jul 14, 2022 at 4:59 AM Xianting Tian
> <xianting.tian@linux.alibaba.com> 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

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH V2 2/2] riscv: Add modules to virtual kernel memory layout dump
@ 2022-07-14  9:17       ` Xianting Tian
  0 siblings, 0 replies; 14+ messages in thread
From: Xianting Tian @ 2022-07-14  9:17 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
	Guo Ren, Anup Patel, Nick Kossifidis, Mike Rapoport,
	Heiko Stuebner, linux-riscv, Linux Kernel Mailing List,
	huanyi.xj


在 2022/7/14 下午4:24, Arnd Bergmann 写道:
> On Thu, Jul 14, 2022 at 4:59 AM Xianting Tian
> <xianting.tian@linux.alibaba.com> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH V2 2/2] riscv: Add modules to virtual kernel memory layout dump
  2022-07-14  9:17       ` Xianting Tian
@ 2022-07-14  9:46         ` Heiko Stübner
  -1 siblings, 0 replies; 14+ messages in thread
From: Heiko Stübner @ 2022-07-14  9:46 UTC (permalink / raw)
  To: Arnd Bergmann, Xianting Tian
  Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
	Guo Ren, Anup Patel, Nick Kossifidis, Mike Rapoport, linux-riscv,
	Linux Kernel Mailing List, huanyi.xj

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
> > <xianting.tian@linux.alibaba.com> 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




_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH V2 2/2] riscv: Add modules to virtual kernel memory layout dump
@ 2022-07-14  9:46         ` Heiko Stübner
  0 siblings, 0 replies; 14+ messages in thread
From: Heiko Stübner @ 2022-07-14  9:46 UTC (permalink / raw)
  To: Arnd Bergmann, Xianting Tian
  Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
	Guo Ren, Anup Patel, Nick Kossifidis, Mike Rapoport, linux-riscv,
	Linux Kernel Mailing List, huanyi.xj

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
> > <xianting.tian@linux.alibaba.com> 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




^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH V2 2/2] riscv: Add modules to virtual kernel memory layout dump
  2022-07-14  9:46         ` Heiko Stübner
@ 2022-07-14 11:06           ` Xianting Tian
  -1 siblings, 0 replies; 14+ messages in thread
From: Xianting Tian @ 2022-07-14 11:06 UTC (permalink / raw)
  To: Heiko Stübner, Arnd Bergmann
  Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
	Guo Ren, Anup Patel, Nick Kossifidis, Mike Rapoport, linux-riscv,
	Linux Kernel Mailing List, huanyi.xj


在 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
>>> <xianting.tian@linux.alibaba.com> 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
>
>

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [PATCH V2 2/2] riscv: Add modules to virtual kernel memory layout dump
@ 2022-07-14 11:06           ` Xianting Tian
  0 siblings, 0 replies; 14+ messages in thread
From: Xianting Tian @ 2022-07-14 11:06 UTC (permalink / raw)
  To: Heiko Stübner, Arnd Bergmann
  Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
	Guo Ren, Anup Patel, Nick Kossifidis, Mike Rapoport, linux-riscv,
	Linux Kernel Mailing List, huanyi.xj


在 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
>>> <xianting.tian@linux.alibaba.com> 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
>
>

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~2022-07-14 11:06 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-14  2:58 [PATCH V2 0/2] Improve vmcoreinfo and memory layout dump Xianting Tian
2022-07-14  2:58 ` Xianting Tian
2022-07-14  2:59 ` [PATCH V2 1/2] RISC-V: Add arch_crash_save_vmcoreinfo support Xianting Tian
2022-07-14  2:59   ` Xianting Tian
2022-07-14  2:59 ` [PATCH V2 2/2] riscv: Add modules to virtual kernel memory layout dump Xianting Tian
2022-07-14  2:59   ` Xianting Tian
2022-07-14  8:24   ` Arnd Bergmann
2022-07-14  8:24     ` Arnd Bergmann
2022-07-14  9:17     ` Xianting Tian
2022-07-14  9:17       ` Xianting Tian
2022-07-14  9:46       ` Heiko Stübner
2022-07-14  9:46         ` Heiko Stübner
2022-07-14 11:06         ` Xianting Tian
2022-07-14 11:06           ` Xianting Tian

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.