forked from Minki/linux
b18eb2d779
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> |
||
|---|---|---|
| .. | ||
| extable.c | ||
| fault_32.c | ||
| fault_64.c | ||
| gup.c | ||
| highmem.c | ||
| hugetlbpage.c | ||
| hypersparc.S | ||
| init_32.c | ||
| init_64.c | ||
| init_64.h | ||
| io-unit.c | ||
| iommu.c | ||
| leon_mm.c | ||
| Makefile | ||
| srmmu_access.S | ||
| srmmu.c | ||
| srmmu.h | ||
| swift.S | ||
| tlb.c | ||
| tsb.c | ||
| tsunami.S | ||
| ultra.S | ||
| viking.S | ||