Without these fences, it is perfectly valid for an out-of-order core to
re-order memory accesses to outside of the available_harts_lock critical
section.

Signed-off-by: Sean Anderson <sean...@gmail.com>
---

 arch/riscv/cpu/start.S | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index e3222b1ea7..ad18e746b6 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -126,12 +126,12 @@ call_board_init_f_0:
 #ifndef CONFIG_XIP
        la      t0, available_harts_lock
        fence   rw, w
-       amoswap.w zero, zero, 0(t0)
+       amoswap.w.rl zero, zero, 0(t0)
 
 wait_for_gd_init:
        la      t0, available_harts_lock
        li      t1, 1
-1:     amoswap.w t1, t1, 0(t0)
+1:     amoswap.w.aq t1, t1, 0(t0)
        fence   r, rw
        bnez    t1, 1b
 
@@ -143,7 +143,7 @@ wait_for_gd_init:
        SREG    t2, GD_AVAILABLE_HARTS(gp)
 
        fence   rw, w
-       amoswap.w zero, zero, 0(t0)
+       amoswap.w.rl zero, zero, 0(t0)
 
        /*
         * Continue on hart lottery winner, others branch to
-- 
2.28.0

Reply via email to