On Tue, Jan 26, 2021 at 01:57:13PM +0000, Will Deacon wrote: > > @@ -297,16 +297,20 @@ void __init __no_sanitize_address setup_arch(char > > **cmdline_p) > > */ > > arm64_use_ng_mappings = kaslr_requires_kpti(); > > > > - early_fixmap_init(); > > - early_ioremap_init(); > > - > > - 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(); > > I don't think your patch changes this, but afaict jump_label_init() uses > per-cpu variables via cpus_read_lock(), yet we don't initialise our offset > until later on. Any idea how that works?
We initialize the boot CPU's offset twice during boot, once before this in smp_setup_processor_id(), and once afterwards in smp_prepare_boot_cpu() since setup_per_cpu_areas() will allocate a new region for CPU0. IIUC per-cpu writes before smp_prepare_boot_cpu() are potentially dodgy since they might be copied to other CPUs, but reads are all fine. Mark.
