I didn't find anything unusual. But I think we do need to order the
load/store of esel_next when acquire/release tcd lock. For acquire,
add a data dependency to order the loads of lock and esel_next.
For release, even there already have a "isync" here, but it doesn't
guarantee any memory access order. So we still need "lwsync" for
the two stores for lock and esel_next.
Signed-off-by: Kevin Hao <haoke...@gmail.com>
---
arch/powerpc/mm/tlb_low_64e.S | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/mm/tlb_low_64e.S b/arch/powerpc/mm/tlb_low_64e.S
index e4185581c5a7..964754911987 100644
--- a/arch/powerpc/mm/tlb_low_64e.S
+++ b/arch/powerpc/mm/tlb_low_64e.S
@@ -334,6 +334,8 @@ BEGIN_FTR_SECTION /* CPU_FTR_SMT */
* with tlbilx before overwriting.
*/
+ andi r15,r15,0 /* add a data dependency to order the loards */
+ add r11,r11,r15 /* between the lock and esel_next */
lbz r15,TCD_ESEL_NEXT(r11)
rlwinm r10,r15,16,0xff0000
oris r10,r10,MAS0_TLBSEL(1)@h
@@ -447,6 +449,7 @@ BEGIN_FTR_SECTION
beq cr1,1f /* no unlock if lock was recursively grabbed */
li r15,0
isync
+ lwsync
stb r15,0(r11)
1:
END_FTR_SECTION_IFSET(CPU_FTR_SMT)
--
2.1.0
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
