[PATCH 0/2] init, hugetlb: fix early parameter ordering

[PATCH 0/2] init, hugetlb: fix early parameter ordering

[Zhenghui Hao]

hugetlb records its command line parameters from early_param()
handlers and consumes them later from hugetlb_bootmem_alloc().

Commit d49004c5f0c1 ("arch, mm: consolidate initialization of nodes,
zones and memory map") moved that consumer into mm_core_init_early(),
which runs before the generic parse_early_param() call in
start_kernel().  Architectures that call parse_early_param() from
setup_arch() are not affected, but on parisc the parameters are then
recorded after they have already been consumed and are silently
dropped.

Patch 1/2 moves parse_early_param() before mm_core_init_early(),
together with jump_label_init() and static_call_init() so that the
"parameters may set static keys" guarantee still holds.

Patch 2/2 makes this class of ordering problem non-silent.  It cannot
fire once 1/2 is applied; if you would rather take only the fix,
please drop 2/2.

Not tested on parisc hardware.

Zhenghui Hao (2):
  init: parse early parameters before memory initialization
  hugetlb: report cmdline parameters recorded too late

 init/main.c  |  8 ++++----
 mm/hugetlb.c | 14 ++++++++++++++
 2 files changed, 18 insertions(+), 4 deletions(-)


base-commit: 9b87fdc9af2fbfcdb5c24a64139685ef80f6573f
-- 
2.53.0

[PATCH 1/2] init: parse early parameters before memory initialization

[Zhenghui Hao]

The hugepages=, hugepagesz= and default_hugepagesz= parameters are
recorded by early_param() handlers and consumed by
hugetlb_bootmem_alloc(), which is called from mm_core_init_early().

Commit d49004c5f0c1 ("arch, mm: consolidate initialization of nodes,
zones and memory map") introduced mm_core_init_early() and placed it
immediately after setup_arch(), i.e. before the generic
parse_early_param() call in start_kernel().  Before that commit,
hugetlb_bootmem_alloc() was called from mm_core_init(), which runs
after parse_early_param().

Architectures that call parse_early_param() from setup_arch() are
unaffected, since parse_early_param() only does anything on the first
call.  On parisc, which relies on the generic call, the parameters are
recorded after they have been consumed and are therefore silently
dropped: neither do_early_param() nor obsolete_checksetup() reports
them.  hugetlb_cma= and hugetlb_free_vmemmap= are affected in the same
way, because hugetlb_cma_reserve() and sparse_init() also run from
mm_core_init_early().

Move parse_early_param() before mm_core_init_early().  To keep the
"parameters may set static keys" guarantee, move jump_label_init() and
static_call_init() up as well, so that they still run first.  None of
the functions called from mm_core_init_early() uses static keys, so
running it after jump_label_init() is safe.

Moving the generic call, instead of adding a parse_early_param() call
to parisc setup_arch(), fixes all architectures at once and makes
"early parameters are parsed before memory initialization" an
invariant.

Not tested on parisc hardware.

Fixes: d49004c5f0c1 ("arch, mm: consolidate initialization of nodes, zones and memory map")
Cc: Mike Rapoport (Microsoft) <rppt@kernel.org>
Cc: Helge Deller <deller@gmx.de>
Signed-off-by: Zhenghui Hao <zhenghui.hao@qq.com>
---
 init/main.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/init/main.c b/init/main.c
index 31f2bf54976a..bccf521910be 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1007,10 +1007,12 @@ void start_kernel(void)
 	page_address_init();
 	pr_notice("%s", linux_banner);
 	setup_arch(&command_line);
-	mm_core_init_early();
-	/* Static keys and static calls are needed by LSMs */
+	/* Static keys and static calls are needed by LSMs and early params */
 	jump_label_init();
 	static_call_init();
+	/* parameters may set static keys */
+	parse_early_param();
+	mm_core_init_early();
 	early_security_init();
 	setup_boot_config();
 	setup_command_line(command_line);
@@ -1021,8 +1023,6 @@ void start_kernel(void)
 	boot_cpu_hotplug_init();
 
 	print_kernel_cmdline(saved_command_line);
-	/* parameters may set static keys */
-	parse_early_param();
 	after_dashes = parse_args("Booting kernel",
 				  static_command_line, __start___param,
 				  __stop___param - __start___param,
-- 
2.53.0

[PATCH 2/2] hugetlb: report cmdline parameters recorded too late

[Zhenghui Hao]

hugetlb command line parameters are recorded by the early_param()
handlers registered through hugetlb_early_param() and consumed later by
hugetlb_parse_params(), which is called from hugetlb_bootmem_alloc().

Since commit d49004c5f0c1 ("arch, mm: consolidate initialization of nodes,
zones and memory map") that consumer runs from mm_core_init_early(),
which is called before the generic parse_early_param() in start_kernel().

On architectures that do not call parse_early_param() from setup_arch(),
such as parisc, the parameters are recorded only after they have been
consumed, so they are dropped without any diagnostics: do_early_param()
stays quiet because the handlers return 0, and obsolete_checksetup()
treats early parameters as already handled.

Warn in that case instead of dropping the parameter silently.
Returning non-zero from the wrapper would also work, but it makes
do_early_param() print "Malformed early option", which points at the
command line instead of at the ordering problem, so print an accurate
message and return 0.

The check cannot produce false positives: the wrappers are reachable
only from do_early_param(), and hugetlb_parse_params() is called exactly
once, so once hugetlb_cmdline_consumed is set, any further recording is
by construction too late to be honored.

Not tested on parisc hardware.

Cc: Mike Rapoport (Microsoft) <rppt@kernel.org>
Cc: Helge Deller <deller@gmx.de>
Signed-off-by: Zhenghui Hao <zhenghui.hao@qq.com>
---
 mm/hugetlb.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 4f6f58bf3db6..bda8af614a70 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -91,12 +91,24 @@ static char hstate_cmdline_buf[COMMAND_LINE_SIZE] __initdata;
 static int hstate_cmdline_index __initdata;
 static struct hugetlb_cmdline hugetlb_params[HUGE_MAX_CMDLINE_ARGS] __initdata;
 static int hugetlb_param_index __initdata;
+/*
+ * Set once hugetlb_bootmem_alloc() has consumed the recorded parameters.
+ * A parameter recorded after that point can never be honored, so report it
+ * instead of dropping it silently.  This happens if an architecture calls
+ * parse_early_param() only after mm_core_init_early().
+ */
+static bool hugetlb_cmdline_consumed __initdata;
 static __init int hugetlb_add_param(char *s, int (*setup)(char *val));
 static __init void hugetlb_parse_params(void);
 
 #define hugetlb_early_param(str, func) \
 static __init int func##args(char *s) \
 { \
+	if (hugetlb_cmdline_consumed) { \
+		pr_warn("HugeTLB: %s=%s recorded too late to be honored, ignoring\n", \
+			str, s ?: ""); \
+		return 0; \
+	} \
 	return hugetlb_add_param(s, func); \
 } \
 early_param(str, func##args)
@@ -4491,6 +4503,8 @@ void __init hugetlb_bootmem_alloc(void)
 		INIT_LIST_HEAD(&huge_boot_pages[i]);
 
 	hugetlb_parse_params();
+	/* Anything recorded from here on can no longer be honored. */
+	hugetlb_cmdline_consumed = true;
 
 	for_each_hstate(h) {
 		h->next_nid_to_alloc = first_online_node;
-- 
2.53.0

[PATCH 0/2] init, hugetlb: fix early parameter ordering

[Zhenghui Hao]

hugetlb records its command line parameters from early_param()
handlers and consumes them later from hugetlb_bootmem_alloc().

Commit d49004c5f0c1 ("arch, mm: consolidate initialization of nodes,
zones and memory map") moved that consumer into mm_core_init_early(),
which runs before the generic parse_early_param() call in
start_kernel().  Architectures that call parse_early_param() from
setup_arch() are not affected, but on parisc the parameters are then
recorded after they have already been consumed and are silently
dropped.

Patch 1/2 moves parse_early_param() before mm_core_init_early(),
together with jump_label_init() and static_call_init() so that the
"parameters may set static keys" guarantee still holds.

Patch 2/2 makes this class of ordering problem non-silent.  It cannot
fire once 1/2 is applied; if you would rather take only the fix,
please drop 2/2.

Not tested on parisc hardware.

Zhenghui Hao (2):
  init: parse early parameters before memory initialization
  hugetlb: report cmdline parameters recorded too late

 init/main.c  |  8 ++++----
 mm/hugetlb.c | 14 ++++++++++++++
 2 files changed, 18 insertions(+), 4 deletions(-)


base-commit: 9b87fdc9af2fbfcdb5c24a64139685ef80f6573f
-- 
2.53.0

[PATCH 1/2] init: parse early parameters before memory initialization

[Zhenghui Hao]

The hugepages=, hugepagesz= and default_hugepagesz= parameters are
recorded by early_param() handlers and consumed by
hugetlb_bootmem_alloc(), which is called from mm_core_init_early().

Commit d49004c5f0c1 ("arch, mm: consolidate initialization of nodes,
zones and memory map") introduced mm_core_init_early() and placed it
immediately after setup_arch(), i.e. before the generic
parse_early_param() call in start_kernel().  Before that commit,
hugetlb_bootmem_alloc() was called from mm_core_init(), which runs
after parse_early_param().

Architectures that call parse_early_param() from setup_arch() are
unaffected, since parse_early_param() only does anything on the first
call.  On parisc, which relies on the generic call, the parameters are
recorded after they have been consumed and are therefore silently
dropped: neither do_early_param() nor obsolete_checksetup() reports
them.  hugetlb_cma= and hugetlb_free_vmemmap= are affected in the same
way, because hugetlb_cma_reserve() and sparse_init() also run from
mm_core_init_early().

Move parse_early_param() before mm_core_init_early().  To keep the
"parameters may set static keys" guarantee, move jump_label_init() and
static_call_init() up as well, so that they still run first.  None of
the functions called from mm_core_init_early() uses static keys, so
running it after jump_label_init() is safe.

Moving the generic call, instead of adding a parse_early_param() call
to parisc setup_arch(), fixes all architectures at once and makes
"early parameters are parsed before memory initialization" an
invariant.

Not tested on parisc hardware.

Fixes: d49004c5f0c1 ("arch, mm: consolidate initialization of nodes, zones and memory map")
Cc: Mike Rapoport (Microsoft) <rppt@kernel.org>
Cc: Helge Deller <deller@gmx.de>
Signed-off-by: Zhenghui Hao <zhenghui.hao@qq.com>
---
 init/main.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/init/main.c b/init/main.c
index 31f2bf54976a..bccf521910be 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1007,10 +1007,12 @@ void start_kernel(void)
 	page_address_init();
 	pr_notice("%s", linux_banner);
 	setup_arch(&command_line);
-	mm_core_init_early();
-	/* Static keys and static calls are needed by LSMs */
+	/* Static keys and static calls are needed by LSMs and early params */
 	jump_label_init();
 	static_call_init();
+	/* parameters may set static keys */
+	parse_early_param();
+	mm_core_init_early();
 	early_security_init();
 	setup_boot_config();
 	setup_command_line(command_line);
@@ -1021,8 +1023,6 @@ void start_kernel(void)
 	boot_cpu_hotplug_init();
 
 	print_kernel_cmdline(saved_command_line);
-	/* parameters may set static keys */
-	parse_early_param();
 	after_dashes = parse_args("Booting kernel",
 				  static_command_line, __start___param,
 				  __stop___param - __start___param,
-- 
2.53.0

[PATCH 2/2] hugetlb: report cmdline parameters recorded too late

[Zhenghui Hao]

hugetlb command line parameters are recorded by the early_param()
handlers registered through hugetlb_early_param() and consumed later by
hugetlb_parse_params(), which is called from hugetlb_bootmem_alloc().

Since commit d49004c5f0c1 ("arch, mm: consolidate initialization of nodes,
zones and memory map") that consumer runs from mm_core_init_early(),
which is called before the generic parse_early_param() in start_kernel().

On architectures that do not call parse_early_param() from setup_arch(),
such as parisc, the parameters are recorded only after they have been
consumed, so they are dropped without any diagnostics: do_early_param()
stays quiet because the handlers return 0, and obsolete_checksetup()
treats early parameters as already handled.

Warn in that case instead of dropping the parameter silently.
Returning non-zero from the wrapper would also work, but it makes
do_early_param() print "Malformed early option", which points at the
command line instead of at the ordering problem, so print an accurate
message and return 0.

The check cannot produce false positives: the wrappers are reachable
only from do_early_param(), and hugetlb_parse_params() is called exactly
once, so once hugetlb_cmdline_consumed is set, any further recording is
by construction too late to be honored.

Not tested on parisc hardware.

Cc: Mike Rapoport (Microsoft) <rppt@kernel.org>
Cc: Helge Deller <deller@gmx.de>
Signed-off-by: Zhenghui Hao <zhenghui.hao@qq.com>
---
 mm/hugetlb.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 4f6f58bf3db6..bda8af614a70 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -91,12 +91,24 @@ static char hstate_cmdline_buf[COMMAND_LINE_SIZE] __initdata;
 static int hstate_cmdline_index __initdata;
 static struct hugetlb_cmdline hugetlb_params[HUGE_MAX_CMDLINE_ARGS] __initdata;
 static int hugetlb_param_index __initdata;
+/*
+ * Set once hugetlb_bootmem_alloc() has consumed the recorded parameters.
+ * A parameter recorded after that point can never be honored, so report it
+ * instead of dropping it silently.  This happens if an architecture calls
+ * parse_early_param() only after mm_core_init_early().
+ */
+static bool hugetlb_cmdline_consumed __initdata;
 static __init int hugetlb_add_param(char *s, int (*setup)(char *val));
 static __init void hugetlb_parse_params(void);
 
 #define hugetlb_early_param(str, func) \
 static __init int func##args(char *s) \
 { \
+	if (hugetlb_cmdline_consumed) { \
+		pr_warn("HugeTLB: %s=%s recorded too late to be honored, ignoring\n", \
+			str, s ?: ""); \
+		return 0; \
+	} \
 	return hugetlb_add_param(s, func); \
 } \
 early_param(str, func##args)
@@ -4491,6 +4503,8 @@ void __init hugetlb_bootmem_alloc(void)
 		INIT_LIST_HEAD(&huge_boot_pages[i]);
 
 	hugetlb_parse_params();
+	/* Anything recorded from here on can no longer be honored. */
+	hugetlb_cmdline_consumed = true;
 
 	for_each_hstate(h) {
 		h->next_nid_to_alloc = first_online_node;
-- 
2.53.0

[PATCH 0/2] init, hugetlb: fix early parameter ordering

[Mike Rapoport]

Hi,

On 2026-09-17 14:55 +0800, Zhenghui Hao wrote:
> hugetlb records its command line parameters from early_param()
> handlers and consumes them later from hugetlb_bootmem_alloc().
> 
> Commit d49004c5f0c1 ("arch, mm: consolidate initialization of nodes,
> zones and memory map") moved that consumer into mm_core_init_early(),
> which runs before the generic parse_early_param() call in
> start_kernel().  Architectures that call parse_early_param() from
> setup_arch() are not affected, but on parisc the parameters are then
> recorded after they have already been consumed and are silently
> dropped.

Since parisc is one of very few architectures that does not call
parse_early_param() from setup_arch(), I think an easier fix would be
local to parisc.

And there is another related question more to parisc maintainers: do we
really need hugetlb on parisc these days?

> Patch 1/2 moves parse_early_param() before mm_core_init_early(),
> together with jump_label_init() and static_call_init() so that the
> "parameters may set static keys" guarantee still holds.
> 
> Patch 2/2 makes this class of ordering problem non-silent.  It cannot
> fire once 1/2 is applied; if you would rather take only the fix,
> please drop 2/2.
> 
> Not tested on parisc hardware.
> 
> Zhenghui Hao (2):
>   init: parse early parameters before memory initialization
>   hugetlb: report cmdline parameters recorded too late
> 
>  init/main.c  |  8 ++++----
>  mm/hugetlb.c | 14 ++++++++++++++
>  2 files changed, 18 insertions(+), 4 deletions(-)
> 
> 
> base-commit: 9b87fdc9af2fbfcdb5c24a64139685ef80f6573f
> -- 
> 2.53.0
> 
> 

Re: [PATCH 0/2] init, hugetlb: fix early parameter ordering

[758910018]

[-- Attachment #1: Type: text/plain, Size: 3934 bytes --]

Hi,


> Since parisc is one of very few architectures that does not call
> parse_early_param() from setup_arch(), I think an easier fix would be
> local to parisc.


Agreed, that is simpler.


Whether a fix is needed at all depends on the answer to your second
question.  If hugetlb is not needed on parisc anymore, there is nothing
left to fix and I will drop this series.  If it stays, I will send v2
with the change inside parisc's setup_arch(), keeping 2/2 so that the
same kind of ordering problem would at least show up in the log.


So I will wait for the parisc maintainers on that one.


Thanks,
Zhenghui






---Original---
From: "Mike Rapoport"<rppt@kernel.org&gt;
Date: Thu, Sep 17, 2026 15:41 PM
To: "Zhenghui Hao"<zhenghui.hao@qq.com&gt;;
Cc: "Andrew Morton"<akpm@linux-foundation.org&gt;;"linux-mm"<linux-mm@kvack.org&gt;;"linux-parisc"<linux-parisc@vger.kernel.org&gt;;"linux-kernel"<linux-kernel@vger.kernel.org&gt;;
Subject: [PATCH 0/2] init, hugetlb: fix early parameter ordering


Hi,

On&nbsp;2026-09-17&nbsp;14:55&nbsp;+0800,&nbsp;Zhenghui&nbsp;Hao&nbsp;wrote:
&gt;&nbsp;hugetlb&nbsp;records&nbsp;its&nbsp;command&nbsp;line&nbsp;parameters&nbsp;from&nbsp;early_param()
&gt;&nbsp;handlers&nbsp;and&nbsp;consumes&nbsp;them&nbsp;later&nbsp;from&nbsp;hugetlb_bootmem_alloc().
&gt;&nbsp;
&gt;&nbsp;Commit&nbsp;d49004c5f0c1&nbsp;("arch,&nbsp;mm:&nbsp;consolidate&nbsp;initialization&nbsp;of&nbsp;nodes,
&gt;&nbsp;zones&nbsp;and&nbsp;memory&nbsp;map")&nbsp;moved&nbsp;that&nbsp;consumer&nbsp;into&nbsp;mm_core_init_early(),
&gt;&nbsp;which&nbsp;runs&nbsp;before&nbsp;the&nbsp;generic&nbsp;parse_early_param()&nbsp;call&nbsp;in
&gt;&nbsp;start_kernel().&nbsp;&nbsp;Architectures&nbsp;that&nbsp;call&nbsp;parse_early_param()&nbsp;from
&gt;&nbsp;setup_arch()&nbsp;are&nbsp;not&nbsp;affected,&nbsp;but&nbsp;on&nbsp;parisc&nbsp;the&nbsp;parameters&nbsp;are&nbsp;then
&gt;&nbsp;recorded&nbsp;after&nbsp;they&nbsp;have&nbsp;already&nbsp;been&nbsp;consumed&nbsp;and&nbsp;are&nbsp;silently
&gt;&nbsp;dropped.

Since&nbsp;parisc&nbsp;is&nbsp;one&nbsp;of&nbsp;very&nbsp;few&nbsp;architectures&nbsp;that&nbsp;does&nbsp;not&nbsp;call
parse_early_param()&nbsp;from&nbsp;setup_arch(),&nbsp;I&nbsp;think&nbsp;an&nbsp;easier&nbsp;fix&nbsp;would&nbsp;be
local&nbsp;to&nbsp;parisc.

And&nbsp;there&nbsp;is&nbsp;another&nbsp;related&nbsp;question&nbsp;more&nbsp;to&nbsp;parisc&nbsp;maintainers:&nbsp;do&nbsp;we
really&nbsp;need&nbsp;hugetlb&nbsp;on&nbsp;parisc&nbsp;these&nbsp;days?

&gt;&nbsp;Patch&nbsp;1/2&nbsp;moves&nbsp;parse_early_param()&nbsp;before&nbsp;mm_core_init_early(),
&gt;&nbsp;together&nbsp;with&nbsp;jump_label_init()&nbsp;and&nbsp;static_call_init()&nbsp;so&nbsp;that&nbsp;the
&gt;&nbsp;"parameters&nbsp;may&nbsp;set&nbsp;static&nbsp;keys"&nbsp;guarantee&nbsp;still&nbsp;holds.
&gt;&nbsp;
&gt;&nbsp;Patch&nbsp;2/2&nbsp;makes&nbsp;this&nbsp;class&nbsp;of&nbsp;ordering&nbsp;problem&nbsp;non-silent.&nbsp;&nbsp;It&nbsp;cannot
&gt;&nbsp;fire&nbsp;once&nbsp;1/2&nbsp;is&nbsp;applied;&nbsp;if&nbsp;you&nbsp;would&nbsp;rather&nbsp;take&nbsp;only&nbsp;the&nbsp;fix,
&gt;&nbsp;please&nbsp;drop&nbsp;2/2.
&gt;&nbsp;
&gt;&nbsp;Not&nbsp;tested&nbsp;on&nbsp;parisc&nbsp;hardware.
&gt;&nbsp;
&gt;&nbsp;Zhenghui&nbsp;Hao&nbsp;(2):
&gt;&nbsp;&nbsp;&nbsp;init:&nbsp;parse&nbsp;early&nbsp;parameters&nbsp;before&nbsp;memory&nbsp;initialization
&gt;&nbsp;&nbsp;&nbsp;hugetlb:&nbsp;report&nbsp;cmdline&nbsp;parameters&nbsp;recorded&nbsp;too&nbsp;late
&gt;&nbsp;
&gt;&nbsp;&nbsp;init/main.c&nbsp;&nbsp;|&nbsp;&nbsp;8&nbsp;++++----
&gt;&nbsp;&nbsp;mm/hugetlb.c&nbsp;|&nbsp;14&nbsp;++++++++++++++
&gt;&nbsp;&nbsp;2&nbsp;files&nbsp;changed,&nbsp;18&nbsp;insertions(+),&nbsp;4&nbsp;deletions(-)
&gt;&nbsp;
&gt;&nbsp;
&gt;&nbsp;base-commit:&nbsp;9b87fdc9af2fbfcdb5c24a64139685ef80f6573f
&gt;&nbsp;--&nbsp;
&gt;&nbsp;2.53.0
&gt;&nbsp;
&gt;&nbsp;

[-- Attachment #2: Type: text/html, Size: 4910 bytes --]

[PATCH 0/2] init, hugetlb: fix early parameter ordering

[zhenghui.hao]

Hi,

> Since parisc is one of very few architectures that does not call
> parse_early_param() from setup_arch(), I think an easier fix would be
> local to parisc.

Agreed, that is simpler.

Whether a fix is needed at all depends on the answer to your second
question.  If hugetlb is not needed on parisc anymore, there is nothing
left to fix and I will drop this series.  If it stays, I will send v2
with the change inside parisc's setup_arch(), keeping 2/2 so that the
same kind of ordering problem would at least show up in the log.

So I will wait for the parisc maintainers on that one.

Thanks,
Zhenghui

Re: [PATCH 0/2] init, hugetlb: fix early parameter ordering

[Mike Rapoport]

(cc Helge)

And please don't post on the Linux kernel mailing lists!

On Thu, Sep 17, 2026 at 04:53:49PM +0800, 758910018 wrote:
> Hi,
> 
> > Since parisc is one of very few architectures that does not call
> > parse_early_param() from setup_arch(), I think an easier fix would be
> > local to parisc.
> 
> Agreed, that is simpler.
> 
> Whether a fix is needed at all depends on the answer to your second
> question.  If hugetlb is not needed on parisc anymore, there is nothing
> left to fix and I will drop this series.  If it stays, I will send v2
> with the change inside parisc's setup_arch(), keeping 2/2 so that the
> same kind of ordering problem would at least show up in the log.
> 
> So I will wait for the parisc maintainers on that one.
> 
> Thanks,
> Zhenghui
> 
> 
> ---Original---
> From: "Mike Rapoport"<rppt@kernel.org>
> Date: Thu, Sep 17, 2026 15:41 PM
> To: "Zhenghui Hao"<zhenghui.hao@qq.com>;
> Cc: "Andrew Morton"<akpm@linux-foundation.org>;"linux-mm"<linux-mm@kvack.org>;
> "linux-parisc"<linux-parisc@vger.kernel.org>;"linux-kernel"
> <linux-kernel@vger.kernel.org>;
> Subject: [PATCH 0/2] init, hugetlb: fix early parameter ordering
> 
> Hi,
> 
> On 2026-09-17 14:55 +0800, Zhenghui Hao wrote:
> > hugetlb records its command line parameters from early_param()
> > handlers and consumes them later from hugetlb_bootmem_alloc().
> > 
> > Commit d49004c5f0c1 ("arch, mm: consolidate initialization of nodes,
> > zones and memory map") moved that consumer into mm_core_init_early(),
> > which runs before the generic parse_early_param() call in
> > start_kernel().  Architectures that call parse_early_param() from
> > setup_arch() are not affected, but on parisc the parameters are then
> > recorded after they have already been consumed and are silently
> > dropped.
> 
> Since parisc is one of very few architectures that does not call
> parse_early_param() from setup_arch(), I think an easier fix would be
> local to parisc.
> 
> And there is another related question more to parisc maintainers: do we
> really need hugetlb on parisc these days?
> 
> > Patch 1/2 moves parse_early_param() before mm_core_init_early(),
> > together with jump_label_init() and static_call_init() so that the
> > "parameters may set static keys" guarantee still holds.
> > 
> > Patch 2/2 makes this class of ordering problem non-silent.  It cannot
> > fire once 1/2 is applied; if you would rather take only the fix,
> > please drop 2/2.
> > 
> > Not tested on parisc hardware.
> > 
> > Zhenghui Hao (2):
> >   init: parse early parameters before memory initialization
> >   hugetlb: report cmdline parameters recorded too late
> > 
> >  init/main.c  |  8 ++++----
> >  mm/hugetlb.c | 14 ++++++++++++++
> >  2 files changed, 18 insertions(+), 4 deletions(-)
> > 
> > 
> > base-commit: 9b87fdc9af2fbfcdb5c24a64139685ef80f6573f
> > -- 
> > 2.53.0
> > 
> > 
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH 0/2] init, hugetlb: fix early parameter ordering

[Mike Rapoport]

On Thu, Sep 17, 2026 at 05:19:46PM +0800, zhenghui.hao wrote:
> Hi,
> 
> > Since parisc is one of very few architectures that does not call
> > parse_early_param() from setup_arch(), I think an easier fix would be
> > local to parisc.
 

you should really fix your email setup :/

> Agreed, that is simpler.
> 
> Whether a fix is needed at all depends on the answer to your second
> question.  If hugetlb is not needed on parisc anymore, there is nothing
> left to fix and I will drop this series.  If it stays, I will send v2
> with the change inside parisc's setup_arch(), keeping 2/2 so that the
> same kind of ordering problem would at least show up in the log.
> 
> So I will wait for the parisc maintainers on that one.
> 
> Thanks,
> Zhenghui

-- 
Sincerely yours,
Mike.