[PATCH 2/2] powerpc/e6500: hw tablewalk: fix recursive tlb lock on cpu 0
scottwood at freescale.com
Sat May 31 03:01:40 EST 2014
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.com at lists.ozlabs.org] On Behalf Of Scott
> > Wood
> > Sent: Friday, May 23, 2014 12:45 AM
> > To: linuxppc-dev at 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.
More information about the Linuxppc-dev