summaryrefslogtreecommitdiffstats
path: root/arch/openrisc
diff options
context:
space:
mode:
authorStafford Horne <shorne@gmail.com>2017-11-03 12:22:27 +0900
committerStafford Horne <shorne@gmail.com>2017-11-03 14:01:17 +0900
commit610f01b9a88a9ef8b506709a825c17395c56a62a (patch)
treef5d35024cb37e05c03c85029685c57e6cfa43590 /arch/openrisc
parentafa83808817357e10b0a4e6d5b89f7b899dabd49 (diff)
downloadlinux-610f01b9a88a9ef8b506709a825c17395c56a62a.tar.bz2
openrisc: fix possible deadlock scenario during timer sync
OpenRISC borrows its timer sync logic from MIPS, Matt helped to review the OpenRISC implementation and noted that we may suffer the same deadlock case that MIPS has faced. The case being: "the MIPS timer synchronization code contained the possibility of deadlock. If you mark a CPU online before it goes into the synchronize loop, then the boot CPU can schedule a different thread and send IPIs to all "online" CPUs. It gets stuck waiting for the secondary to ack it's IPI, since this secondary CPU has not enabled IRQs yet, and is stuck waiting for the master to synchronise with it. The system then deadlocks." Fix this by moving set_cpu_online() to after timer sync. Reported-by: Matt Redfearn <matt.redfearn@mips.com> Signed-off-by: Stafford Horne <shorne@gmail.com>
Diffstat (limited to 'arch/openrisc')
-rw-r--r--arch/openrisc/kernel/smp.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/arch/openrisc/kernel/smp.c b/arch/openrisc/kernel/smp.c
index 4d80ce6fa045..7d518ee8bddc 100644
--- a/arch/openrisc/kernel/smp.c
+++ b/arch/openrisc/kernel/smp.c
@@ -127,10 +127,10 @@ asmlinkage __init void secondary_start_kernel(void)
/*
* OK, now it's safe to let the boot CPU continue
*/
- set_cpu_online(cpu, true);
complete(&cpu_running);
synchronise_count_slave(cpu);
+ set_cpu_online(cpu, true);
local_irq_enable();