diff options
author | Stafford Horne <shorne@gmail.com> | 2017-11-03 12:22:27 +0900 |
---|---|---|
committer | Stafford Horne <shorne@gmail.com> | 2017-11-03 14:01:17 +0900 |
commit | 610f01b9a88a9ef8b506709a825c17395c56a62a (patch) | |
tree | f5d35024cb37e05c03c85029685c57e6cfa43590 /arch/arm/mm/iomap.c | |
parent | afa83808817357e10b0a4e6d5b89f7b899dabd49 (diff) | |
download | linux-stable-610f01b9a88a9ef8b506709a825c17395c56a62a.tar.gz linux-stable-610f01b9a88a9ef8b506709a825c17395c56a62a.tar.bz2 linux-stable-610f01b9a88a9ef8b506709a825c17395c56a62a.zip |
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/arm/mm/iomap.c')
0 files changed, 0 insertions, 0 deletions