While jump_label_init() was moved earlier in the boot process in commit
efd9e03facd0 ("arm64: Use static keys for CPU features"), it wasn't
early enough for early params to use it. The old state of things was as
described here...
init/main.c calls out to arch-specific things before general jump
label and early param handling:
asmlinkage __visible void __init start_kernel(void)
{
...
setup_arch(&command_line);
...
smp_prepare_boot_cpu();
...
/* parameters may set static keys */
jump_label_init();
parse_early_param();
...
}
x86 setup_arch() wants those earlier, so it handles jump label and
early param:
void __init setup_arch(char **cmdline_p)
{
...
jump_label_init();
...
parse_early_param();
...
}
arm64 setup_arch() only had early param:
void __init setup_arch(char **cmdline_p)
{
...
parse_early_param();
...
}
with jump label later in smp_prepare_boot_cpu():
void __init smp_prepare_boot_cpu(void)
{
...
jump_label_init();
...
}
This moves arm64 jump_label_init() from smp_prepare_boot_cpu() to
setup_arch(), as done already on x86, in preparation from early param
usage in the init_on_alloc/free() series:
https://lkml.kernel.org/r/[email protected]
Signed-off-by: Kees Cook <[email protected]>
---
arch/arm64/kernel/setup.c | 5 +++++
arch/arm64/kernel/smp.c | 5 -----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 7e541f947b4c..9c4bad7d7131 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -283,6 +283,11 @@ void __init setup_arch(char **cmdline_p)
setup_machine_fdt(__fdt_pointer);
+ /*
+ * Initialise the static keys early as they may be enabled by the
+ * cpufeature code and early parameters.
+ */
+ jump_label_init();
parse_early_param();
/*
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 6dcf9607d770..20c456b3862c 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -424,11 +424,6 @@ void __init smp_cpus_done(unsigned int max_cpus)
void __init smp_prepare_boot_cpu(void)
{
set_my_cpu_offset(per_cpu_offset(smp_processor_id()));
- /*
- * Initialise the static keys early as they may be enabled by the
- * cpufeature code.
- */
- jump_label_init();
cpuinfo_store_boot_cpu();
/*
--
2.17.1
--
Kees Cook
On Wed, 26 Jun 2019 at 22:51, Kees Cook <[email protected]> wrote:
>
> While jump_label_init() was moved earlier in the boot process in commit
> efd9e03facd0 ("arm64: Use static keys for CPU features"), it wasn't
> early enough for early params to use it. The old state of things was as
> described here...
>
> init/main.c calls out to arch-specific things before general jump
> label and early param handling:
>
> asmlinkage __visible void __init start_kernel(void)
> {
> ...
> setup_arch(&command_line);
> ...
> smp_prepare_boot_cpu();
> ...
> /* parameters may set static keys */
> jump_label_init();
> parse_early_param();
> ...
> }
>
> x86 setup_arch() wants those earlier, so it handles jump label and
> early param:
>
> void __init setup_arch(char **cmdline_p)
> {
> ...
> jump_label_init();
> ...
> parse_early_param();
> ...
> }
>
> arm64 setup_arch() only had early param:
>
> void __init setup_arch(char **cmdline_p)
> {
> ...
> parse_early_param();
> ...
> }
>
> with jump label later in smp_prepare_boot_cpu():
>
> void __init smp_prepare_boot_cpu(void)
> {
> ...
> jump_label_init();
> ...
> }
>
> This moves arm64 jump_label_init() from smp_prepare_boot_cpu() to
> setup_arch(), as done already on x86, in preparation from early param
> usage in the init_on_alloc/free() series:
> https://lkml.kernel.org/r/[email protected]
>
> Signed-off-by: Kees Cook <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
> ---
> arch/arm64/kernel/setup.c | 5 +++++
> arch/arm64/kernel/smp.c | 5 -----
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 7e541f947b4c..9c4bad7d7131 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -283,6 +283,11 @@ void __init setup_arch(char **cmdline_p)
>
> setup_machine_fdt(__fdt_pointer);
>
> + /*
> + * Initialise the static keys early as they may be enabled by the
> + * cpufeature code and early parameters.
> + */
> + jump_label_init();
> parse_early_param();
>
> /*
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 6dcf9607d770..20c456b3862c 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -424,11 +424,6 @@ void __init smp_cpus_done(unsigned int max_cpus)
> void __init smp_prepare_boot_cpu(void)
> {
> set_my_cpu_offset(per_cpu_offset(smp_processor_id()));
> - /*
> - * Initialise the static keys early as they may be enabled by the
> - * cpufeature code.
> - */
> - jump_label_init();
> cpuinfo_store_boot_cpu();
>
> /*
> --
> 2.17.1
>
>
> --
> Kees Cook
Hi Kees,
On Wed, Jun 26, 2019 at 01:51:15PM -0700, Kees Cook wrote:
> This moves arm64 jump_label_init() from smp_prepare_boot_cpu() to
> setup_arch(), as done already on x86, in preparation from early param
> usage in the init_on_alloc/free() series:
> https://lkml.kernel.org/r/[email protected]
This looks fine to me. Is there any other series to be merged soon that
depends on this patch (the init_on_alloc/fail one)? If not, I can queue
it for 5.3.
--
Catalin
On Thu, Jun 27, 2019 at 09:02:08AM +0100, Catalin Marinas wrote:
> On Wed, Jun 26, 2019 at 01:51:15PM -0700, Kees Cook wrote:
> > This moves arm64 jump_label_init() from smp_prepare_boot_cpu() to
> > setup_arch(), as done already on x86, in preparation from early param
> > usage in the init_on_alloc/free() series:
> > https://lkml.kernel.org/r/[email protected]
>
> This looks fine to me. Is there any other series to be merged soon that
> depends on this patch (the init_on_alloc/fail one)? If not, I can queue
> it for 5.3.
Yes, but that series will be in 5.3 also, so there's rush for 5.2. Do
you want Alexander (via akpm) to include it in his series instead of it going
through the arm64 tree?
--
Kees Cook
On Thu, Jun 27, 2019 at 08:58:03AM -0700, Kees Cook wrote:
> On Thu, Jun 27, 2019 at 09:02:08AM +0100, Catalin Marinas wrote:
> > On Wed, Jun 26, 2019 at 01:51:15PM -0700, Kees Cook wrote:
> > > This moves arm64 jump_label_init() from smp_prepare_boot_cpu() to
> > > setup_arch(), as done already on x86, in preparation from early param
> > > usage in the init_on_alloc/free() series:
> > > https://lkml.kernel.org/r/[email protected]
> >
> > This looks fine to me. Is there any other series to be merged soon that
> > depends on this patch (the init_on_alloc/fail one)? If not, I can queue
> > it for 5.3.
>
> Yes, but that series will be in 5.3 also, so there's rush for 5.2. Do
> you want Alexander (via akpm) to include it in his series instead of it going
> through the arm64 tree?
It's pretty late for 5.2, especially since it hasn't had extensive
testing (though I'm fairly sure it won't break). Anyway, it's better if
it goes together with Alexander's series.
Acked-by: Catalin Marinas <[email protected]>
On Thu, Jun 27, 2019 at 6:25 PM Catalin Marinas <[email protected]> wrote:
>
> On Thu, Jun 27, 2019 at 08:58:03AM -0700, Kees Cook wrote:
> > On Thu, Jun 27, 2019 at 09:02:08AM +0100, Catalin Marinas wrote:
> > > On Wed, Jun 26, 2019 at 01:51:15PM -0700, Kees Cook wrote:
> > > > This moves arm64 jump_label_init() from smp_prepare_boot_cpu() to
> > > > setup_arch(), as done already on x86, in preparation from early param
> > > > usage in the init_on_alloc/free() series:
> > > > https://lkml.kernel.org/r/[email protected]
> > >
> > > This looks fine to me. Is there any other series to be merged soon that
> > > depends on this patch (the init_on_alloc/fail one)? If not, I can queue
> > > it for 5.3.
> >
> > Yes, but that series will be in 5.3 also, so there's rush for 5.2. Do
> > you want Alexander (via akpm) to include it in his series instead of it going
> > through the arm64 tree?
>
> It's pretty late for 5.2, especially since it hasn't had extensive
> testing (though I'm fairly sure it won't break). Anyway, it's better if
> it goes together with Alexander's series.
Am I understanding right this is already covered by Kees having sent
his patch to -mm tree and I don't need to explicitly include it into
my series?
> Acked-by: Catalin Marinas <[email protected]>
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
On Fri, Jun 28, 2019 at 11:26:34AM +0200, Alexander Potapenko wrote:
> Am I understanding right this is already covered by Kees having sent
> his patch to -mm tree and I don't need to explicitly include it into
> my series?
Correct; Andrew added it to -mm already.
--
Kees Cook