On 17/08/16 13:51, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
The patch below does not apply to the 4.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@xxxxxxxxxxxxxxx>.
Greg,
I will send the backported version for 4.4 soon.
Thanks
Suzuki
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 9113c2aa05e9848cd4f1154abee17d4f265f012d Mon Sep 17 00:00:00 2001
From: Suzuki K Poulose <suzuki.poulose@xxxxxxx>
Date: Thu, 21 Jul 2016 11:12:55 +0100
Subject: [PATCH] arm64: Fix incorrect per-cpu usage for boot CPU
In smp_prepare_boot_cpu(), we invoke cpuinfo_store_boot_cpu to store
the cpuinfo in a per-cpu ptr, before initialising the per-cpu offset for
the boot CPU. This patch reorders the sequence to make sure we initialise
the per-cpu offset before accessing the per-cpu area.
Commit 4b998ff1885eec ("arm64: Delay cpuinfo_store_boot_cpu") fixed the
issue where we modified the per-cpu area even before the kernel initialises
the per-cpu areas, but failed to wait until the boot cpu updated it's
offset.
Fixes: 4b998ff1885e ("arm64: Delay cpuinfo_store_boot_cpu")
Cc: <stable@xxxxxxxxxxxxxxx> # 4.4+
Cc: Will Deacon <will.deacon@xxxxxxx>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@xxxxxxx>
Acked-by: Mark Rutland <mark.rutland@xxxxxxx>
Signed-off-by: Catalin Marinas <catalin.marinas@xxxxxxx>
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index c0a772560ab7..298dd745651e 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -436,9 +436,9 @@ 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()));
cpuinfo_store_boot_cpu();
save_boot_cpu_run_el();
- set_my_cpu_offset(per_cpu_offset(smp_processor_id()));
}
static u64 __init of_get_cpu_mpidr(struct device_node *dn)
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html