2023-06-13 23:48:24

by Thomas Gleixner

[permalink] [raw]
Subject: [patch 12/17] init: Invoke arch_cpu_finalize_init() earlier

X86 is reworking the boot process so that initializations which are not
required during early boot can be moved into the late boot process and out
of the fragile and restricted initial boot phase.

arch_cpu_finalize_init() is the obvious place to do such initializations,
but arch_cpu_finalize_init() is invoked too late in start_kernel() e.g. for
initializing the FPU completely. fork_init() requires that the FPU is
initialized as the size of task_struct on X86 depends on the size of the
required FPU register buffer.

Fortunately none of the init calls between calibrate_delay() and
arch_cpu_finalize_init() is relevant for the functionality of
arch_cpu_finalize_init().

Invoke it right after calibrate_delay() where everything which is relevant
for arch_cpu_finalize_init() has been set up already.

No functional change intended.

Signed-off-by: Thomas Gleixner <[email protected]>
---
init/main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

--- a/init/main.c
+++ b/init/main.c
@@ -1041,6 +1041,8 @@ asmlinkage __visible void __init __no_sa
sched_clock_init();
calibrate_delay();

+ arch_cpu_finalize_init();
+
/*
* This needs to be called before any devices perform DMA
* operations that might use the SWIOTLB bounce buffers. It will
@@ -1077,8 +1079,6 @@ asmlinkage __visible void __init __no_sa
taskstats_init_early();
delayacct_init();

- arch_cpu_finalize_init();
-
acpi_subsystem_init();
arch_post_acpi_subsys_init();
kcsan_init();



2023-06-15 22:10:21

by Thomas Gleixner

[permalink] [raw]
Subject: Re: [patch 12/17] init: Invoke arch_cpu_finalize_init() earlier

On Thu, Jun 15 2023 at 21:44, Rick P. Edgecombe wrote:
> On Wed, 2023-06-14 at 01:39 +0200, Thomas Gleixner wrote:
>> Fortunately none of the init calls between calibrate_delay() and
>> arch_cpu_finalize_init() is relevant for the functionality of
>> arch_cpu_finalize_init().
>>
>
> Reviewed-by: Rick Edgecombe <[email protected]>
>
> I did my best to find a counterpoint to this statement. The only thing
> I found was that lockdep_init_task(&init_task) in fork_init() is now
> called after the spin_lock() usage in set_memory_4k().
>
> But AFAICT, that whole lockdep_init_task() call is unneeded because
> the fields it sets are already statically initialized.

Correct. The call there looks absolute pointless. Peter?

2023-06-15 22:10:46

by Edgecombe, Rick P

[permalink] [raw]
Subject: Re: [patch 12/17] init: Invoke arch_cpu_finalize_init() earlier

On Wed, 2023-06-14 at 01:39 +0200, Thomas Gleixner wrote:
> Fortunately none of the init calls between calibrate_delay() and
> arch_cpu_finalize_init() is relevant for the functionality of
> arch_cpu_finalize_init().
>

Reviewed-by: Rick Edgecombe <[email protected]>

I did my best to find a counterpoint to this statement. The only thing
I found was that lockdep_init_task(&init_task) in fork_init() is now
called after the spin_lock() usage in set_memory_4k(). But AFAICT, that
whole lockdep_init_task() call is unneeded because the fields it sets
are already statically initialized. I mention only because I'm not 100%
sure the lockdep_init_task() call is not serving some purpose I'm
missing.

Subject: [tip: x86/boot] init: Invoke arch_cpu_finalize_init() earlier

The following commit has been merged into the x86/boot branch of tip:

Commit-ID: 9df9d2f0471b4c4702670380b8d8a45b40b23a7d
Gitweb: https://git.kernel.org/tip/9df9d2f0471b4c4702670380b8d8a45b40b23a7d
Author: Thomas Gleixner <[email protected]>
AuthorDate: Wed, 14 Jun 2023 01:39:39 +02:00
Committer: Thomas Gleixner <[email protected]>
CommitterDate: Fri, 16 Jun 2023 10:16:00 +02:00

init: Invoke arch_cpu_finalize_init() earlier

X86 is reworking the boot process so that initializations which are not
required during early boot can be moved into the late boot process and out
of the fragile and restricted initial boot phase.

arch_cpu_finalize_init() is the obvious place to do such initializations,
but arch_cpu_finalize_init() is invoked too late in start_kernel() e.g. for
initializing the FPU completely. fork_init() requires that the FPU is
initialized as the size of task_struct on X86 depends on the size of the
required FPU register buffer.

Fortunately none of the init calls between calibrate_delay() and
arch_cpu_finalize_init() is relevant for the functionality of
arch_cpu_finalize_init().

Invoke it right after calibrate_delay() where everything which is relevant
for arch_cpu_finalize_init() has been set up already.

No functional change intended.

Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Rick Edgecombe <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

---
init/main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/init/main.c b/init/main.c
index 389ac62..c968c19 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1041,6 +1041,8 @@ asmlinkage __visible void __init __no_sanitize_address __noreturn start_kernel(v
sched_clock_init();
calibrate_delay();

+ arch_cpu_finalize_init();
+
/*
* This needs to be called before any devices perform DMA
* operations that might use the SWIOTLB bounce buffers. It will
@@ -1077,8 +1079,6 @@ asmlinkage __visible void __init __no_sanitize_address __noreturn start_kernel(v
taskstats_init_early();
delayacct_init();

- arch_cpu_finalize_init();
-
acpi_subsystem_init();
arch_post_acpi_subsys_init();
kcsan_init();