From: "Heiko Stübner" <heiko@sntech.de>
To: Arnd Bergmann <arnd@arndb.de>,
Xianting Tian <xianting.tian@linux.alibaba.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alexandre.ghiti@canonical.com>,
Guo Ren <guoren@kernel.org>, Anup Patel <anup@brainfault.org>,
Nick Kossifidis <mick@ics.forth.gr>,
Mike Rapoport <rppt@kernel.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
huanyi.xj@alibaba-inc.com
Subject: Re: [PATCH V2 2/2] riscv: Add modules to virtual kernel memory layout dump
Date: Thu, 14 Jul 2022 11:46:20 +0200 [thread overview]
Message-ID: <3975689.5fSG56mABF@diego> (raw)
In-Reply-To: <f706ddff-8444-bba1-a98a-23a1333cc70a@linux.alibaba.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko@sntech.de>
To: Arnd Bergmann <arnd@arndb.de>,
Xianting Tian <xianting.tian@linux.alibaba.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alexandre.ghiti@canonical.com>,
Guo Ren <guoren@kernel.org>, Anup Patel <anup@brainfault.org>,
Nick Kossifidis <mick@ics.forth.gr>,
Mike Rapoport <rppt@kernel.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
huanyi.xj@alibaba-inc.com
Subject: Re: [PATCH V2 2/2] riscv: Add modules to virtual kernel memory layout dump
Date: Thu, 14 Jul 2022 11:46:20 +0200 [thread overview]
Message-ID: <3975689.5fSG56mABF@diego> (raw)
In-Reply-To: <f706ddff-8444-bba1-a98a-23a1333cc70a@linux.alibaba.com>
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
next prev parent reply other threads:[~2022-07-14 9:46 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2022-07-14 9:46 ` Heiko Stübner
2022-07-14 11:06 ` Xianting Tian
2022-07-14 11:06 ` Xianting Tian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3975689.5fSG56mABF@diego \
--to=heiko@sntech.de \
--cc=alexandre.ghiti@canonical.com \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=arnd@arndb.de \
--cc=guoren@kernel.org \
--cc=huanyi.xj@alibaba-inc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mick@ics.forth.gr \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=rppt@kernel.org \
--cc=xianting.tian@linux.alibaba.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.