Re: [PATCH 2/2] powerpc/e6500: hw tablewalk: fix recursive tlb lock on cpu 0
On Fri, 2014-05-30 at 02:59 -0500, Caraman Mihai Claudiu-B02008 wrote: > > -Original Message- > > From: Linuxppc-dev [mailto:linuxppc-dev- > > bounces+mihai.caraman=freescale@lists.ozlabs.org] On Behalf Of Scott > > Wood > > Sent: Friday, May 23, 2014 12:45 AM > > To: linuxppc-dev@lists.ozlabs.org > > Cc: Wood Scott-B07421 > > Subject: [PATCH 2/2] powerpc/e6500: hw tablewalk: fix recursive tlb lock > > on cpu 0 > > > > Commit 82d86de25b9c99db546e17c6f7ebf9a691da557e "TLB lock recursive" > > introduced a bug whereby cpu 0 uses the same value for "lock held" as > > is used to indicate that the lock is free. > > Isn't his what spin lock implementation solves by combines paca_index > with lock_token? Can't we have a common approach? That would require expanding the lock to 32 bits, is a more intrusive fix than needed, and invites breakage in the TLB code if the lock_token mechanism were to change. > > Add one to the CPU value to ensure we do not use zero as a "lock held" > > value. > > The CPU value is loaded in r10 from tlb_miss_common_e6500. "TLB lock > recursive" > commit also introduced this misleading comment: > > We are entered with: > r10 = cpu number I addressed this in v2 that I posted yesterday. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2] powerpc/e6500: hw tablewalk: fix recursive tlb lock on cpu 0
> -Original Message- > From: Linuxppc-dev [mailto:linuxppc-dev- > bounces+mihai.caraman=freescale@lists.ozlabs.org] On Behalf Of Scott > Wood > Sent: Friday, May 23, 2014 12:45 AM > To: linuxppc-dev@lists.ozlabs.org > Cc: Wood Scott-B07421 > Subject: [PATCH 2/2] powerpc/e6500: hw tablewalk: fix recursive tlb lock > on cpu 0 > > Commit 82d86de25b9c99db546e17c6f7ebf9a691da557e "TLB lock recursive" > introduced a bug whereby cpu 0 uses the same value for "lock held" as > is used to indicate that the lock is free. Isn't his what spin lock implementation solves by combines paca_index with lock_token? Can't we have a common approach? > Add one to the CPU value to ensure we do not use zero as a "lock held" > value. The CPU value is loaded in r10 from tlb_miss_common_e6500. "TLB lock recursive" commit also introduced this misleading comment: We are entered with: r10 = cpu number -Mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/e6500: hw tablewalk: fix recursive tlb lock on cpu 0
Commit 82d86de25b9c99db546e17c6f7ebf9a691da557e "TLB lock recursive" introduced a bug whereby cpu 0 uses the same value for "lock held" as is used to indicate that the lock is free. This means that cpu 1 can acquire the lock whenever it wants, regardless of whether cpu 0 has it locked, which in turn means we can get duplicate TLB entries. Add one to the CPU value to ensure we do not use zero as a "lock held" value. Signed-off-by: Scott Wood --- arch/powerpc/mm/tlb_low_64e.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/mm/tlb_low_64e.S b/arch/powerpc/mm/tlb_low_64e.S index 3298d10..ba3ba3c 100644 --- a/arch/powerpc/mm/tlb_low_64e.S +++ b/arch/powerpc/mm/tlb_low_64e.S @@ -309,6 +309,7 @@ tlb_miss_common_e6500: lhz r10,PACAPACAINDEX(r13) cmpdi r15,0 cmpdi cr1,r15,1 /* set cr1.eq = 0 for non-recursive */ + addir10,r10,1 bne 2f stbcx. r10,0,r11 bne 1b -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
