From: Dev Jain <dev.jain@arm.com>
To: Jia He <justin.he@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Uladzislau Rezki <urezki@gmail.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>,
Ryan Roberts <ryan.roberts@arm.com>, Peter Xu <peterx@redhat.com>,
Joey Gouly <joey.gouly@arm.com>,
Yicong Yang <yangyicong@hisilicon.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm: vmalloc: use VMALLOC_EARLY_START boundary for early vmap area
Date: Tue, 22 Jul 2025 12:18:11 +0530 [thread overview]
Message-ID: <c185e160-1b82-41f6-832d-cef3938a1a9f@arm.com> (raw)
In-Reply-To: <20250722040850.2017769-1-justin.he@arm.com>
On 22/07/25 9:38 am, Jia He wrote:
> When VMALLOC_START is redefined to a new boundary, most subsystems
> continue to function correctly. However, vm_area_register_early()
> assumes the use of the global _vmlist_ structure before vmalloc_init()
> is invoked. This assumption can lead to issues during early boot.
>
> See the calltrace as follows:
> start_kernel()
> setup_per_cpu_areas()
> pcpu_page_first_chunk()
> vm_area_register_early()
> mm_core_init()
> vmalloc_init()
>
> The early vm areas will be added to vmlist at declare_kernel_vmas()
> ->declare_vma():
> ffff800080010000 T _stext
> ffff800080da0000 D __start_rodata
> ffff800081890000 T __inittext_begin
> ffff800081980000 D __initdata_begin
> ffff800081ee0000 D _data
> The starting address of the early areas is tied to the *old* VMALLOC_START
> (i.e. 0xffff800080000000 on an arm64 N2 server).
>
> If VMALLOC_START is redefined, it can disrupt early VM area allocation,
> particularly in like pcpu_page_first_chunk()->vm_area_register_early().
>
> To address this potential risk on arm64, introduce a new boundary,
> VMALLOC_EARLY_START, to avoid boot issues when VMALLOC_START is
> occasionaly redefined.
Sorry but I am unable to understand the point of the patch. If a particular
value of VMALLOC_START causes a problem because the vma declarations of the
kernel are tied to that value, surely we should be reasoning about what was
wrong about the new value, and not circumventing the actual problem
by introducing VMALLOC_EARLY_START?
Also by your patch description I don't think you have run into a reproducible
boot issue, so this patch is basically adding dead code because both macros
are defined to MODULES_END?
>
> Signed-off-by: Jia He <justin.he@arm.com>
> ---
> arch/arm64/include/asm/pgtable.h | 2 ++
> mm/vmalloc.c | 6 +++++-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 192d86e1cc76..91031912a906 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -18,9 +18,11 @@
> * VMALLOC range.
> *
> * VMALLOC_START: beginning of the kernel vmalloc space
> + * VMALLOC_EARLY_START: early vm area before vmalloc_init()
> * VMALLOC_END: extends to the available space below vmemmap
> */
> #define VMALLOC_START (MODULES_END)
> +#define VMALLOC_EARLY_START (MODULES_END)
> #if VA_BITS == VA_BITS_MIN
> #define VMALLOC_END (VMEMMAP_START - SZ_8M)
> #else
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 6dbcdceecae1..86ab1e99641a 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -50,6 +50,10 @@
> #include "internal.h"
> #include "pgalloc-track.h"
>
> +#ifndef VMALLOC_EARLY_START
> +#define VMALLOC_EARLY_START VMALLOC_START
> +#endif
> +
> #ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
> static unsigned int __ro_after_init ioremap_max_page_shift = BITS_PER_LONG - 1;
>
> @@ -3126,7 +3130,7 @@ void __init vm_area_add_early(struct vm_struct *vm)
> */
> void __init vm_area_register_early(struct vm_struct *vm, size_t align)
> {
> - unsigned long addr = ALIGN(VMALLOC_START, align);
> + unsigned long addr = ALIGN(VMALLOC_EARLY_START, align);
> struct vm_struct *cur, **p;
>
> BUG_ON(vmap_initialized);
next prev parent reply other threads:[~2025-07-22 6:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-22 4:08 Jia He
2025-07-22 6:48 ` Dev Jain [this message]
2025-07-28 6:19 ` Justin He
2025-07-29 16:26 ` Dev Jain
2025-07-22 19:39 ` Uladzislau Rezki
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=c185e160-1b82-41f6-832d-cef3938a1a9f@arm.com \
--to=dev.jain@arm.com \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=justin.he@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=peterx@redhat.com \
--cc=ryan.roberts@arm.com \
--cc=urezki@gmail.com \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=yangyicong@hisilicon.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox