sparc64: Fix huge TSB mapping on pre-UltraSPARC-III cpus.
authorDavid S. Miller <davem@davemloft.net>
Wed, 7 May 2014 21:07:32 +0000 (14:07 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 14 Aug 2014 01:38:26 +0000 (09:38 +0800)
commitc184f95bbe3e613461c17ded62206c921a6e64b7
tree926b5c5e1b528fe6a7de5f2371cef7758dd720a5
parent8f0a3c34dd189a5318c23dbb82b3c675669e10e0
sparc64: Fix huge TSB mapping on pre-UltraSPARC-III cpus.

[ Upstream commit b18eb2d779240631a098626cb6841ee2dd34fda0 ]

Access to the TSB hash tables during TLB misses requires that there be
an atomic 128-bit quad load available so that we fetch a matching TAG
and DATA field at the same time.

On cpus prior to UltraSPARC-III only virtual address based quad loads
are available.  UltraSPARC-III and later provide physical address
based variants which are easier to use.

When we only have virtual address based quad loads available this
means that we have to lock the TSB into the TLB at a fixed virtual
address on each cpu when it runs that process.  We can't just access
the PAGE_OFFSET based aliased mapping of these TSBs because we cannot
take a recursive TLB miss inside of the TLB miss handler without
risking running out of hardware trap levels (some trap combinations
can be deep, such as those generated by register window spill and fill
traps).

Without huge pages it's working perfectly fine, but when the huge TSB
got added another chunk of fixed virtual address space was not
allocated for this second TSB mapping.

So we were mapping both the 8K and 4MB TSBs to the same exact virtual
address, causing multiple TLB matches which gives undefined behavior.

Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arch/sparc/include/asm/pgtable_64.h
arch/sparc/mm/tsb.c