Re: [PATCH] ARM: initialize jump labels before setup_machine_fdt()
From: Ard Biesheuvel <ardb@kernel.org>
Date: 2022-06-03 06:53:25
Also in:
lkml, stable
On Thu, 2 Jun 2022 at 23:22, Jason A. Donenfeld [off-list ref] wrote:
Stephen reported that a static key warning splat appears during early
boot on arm64 systems that credit randomness from device trees that
contain an "rng-seed" property, because setup_machine_fdt() is called
before jump_label_init() during setup_arch(), which was fixed by
73e2d827a501 ("arm64: Initialize jump labels before
setup_machine_fdt()").
Upon cursory inspection, the same basic issue appears to apply to arm32
as well. In this case, we reorder setup_arch() to do things in the same
order as is now the case on arm64.
Reported-by: Stephen Boyd <redacted>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: stable@vger.kernel.org
Fixes: f5bda35fba61 ("random: use static branch for crng_ready()")Wouldn't it be better to defer the static_branch_enable(&crng_is_ready) call to later in the boot (e.g., using an initcall()), rather than going around 'fixing' fragile, working early boot code across multiple architectures?
quoted hunk ↗ jump to hunk
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> --- arch/arm/kernel/setup.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c index 1e8a50a97edf..ef40d9f5d5a7 100644 --- a/arch/arm/kernel/setup.c +++ b/arch/arm/kernel/setup.c@@ -1097,10 +1097,15 @@ void __init setup_arch(char **cmdline_p) const struct machine_desc *mdesc = NULL; void *atags_vaddr = NULL; + setup_initial_init_mm(_text, _etext, _edata, _end); + setup_processor(); + early_fixmap_init(); + early_ioremap_init(); + jump_label_init(); +
Is it really necessary to reorder all these calls? What does jump_label_init() actually need? If this is related to the code patching, I wonder whether it wouldn't be better not to rewrite all the NOPs (this is a x86-ism as every new x86 uarch appears to have a better [faster?] NOP than the previous one) The issue with changes like these is that we might end up with bug report in ~3 months' time that 'obscure platform X no longer boots or produces any output'. In the best case, we'll have a bisect report identifying this patch, but we won't be able to simply revert it as it would reintroduce this issue into a kernel that is now stable.
quoted hunk ↗ jump to hunk
if (__atags_pointer) atags_vaddr = FDT_VIRT_BASE(__atags_pointer); - setup_processor(); if (atags_vaddr) { mdesc = setup_machine_fdt(atags_vaddr); if (mdesc)@@ -1125,15 +1130,10 @@ void __init setup_arch(char **cmdline_p) if (mdesc->reboot_mode != REBOOT_HARD) reboot_mode = mdesc->reboot_mode; - setup_initial_init_mm(_text, _etext, _edata, _end); - /* populate cmd_line too for later use, preserving boot_command_line */ strlcpy(cmd_line, boot_command_line, COMMAND_LINE_SIZE); *cmdline_p = cmd_line; - early_fixmap_init(); - early_ioremap_init(); - parse_early_param(); #ifdef CONFIG_MMU --2.35.1
_______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel