Patch "sparc64: Fix huge TSB mapping on pre-UltraSPARC-III cpus." has been added to the 3.10-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    sparc64: Fix huge TSB mapping on pre-UltraSPARC-III cpus.

to the 3.10-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     sparc64-fix-huge-tsb-mapping-on-pre-ultrasparc-iii-cpus.patch
and it can be found in the queue-3.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.


>From foo@baz Fri Aug  8 08:50:32 PDT 2014
From: "David S. Miller" <davem@xxxxxxxxxxxxx>
Date: Wed, 7 May 2014 14:07:32 -0700
Subject: sparc64: Fix huge TSB mapping on pre-UltraSPARC-III cpus.

From: "David S. Miller" <davem@xxxxxxxxxxxxx>

[ 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@xxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
 arch/sparc/include/asm/pgtable_64.h |    6 ++++--
 arch/sparc/mm/tsb.c                 |   14 +++++++++++++-
 2 files changed, 17 insertions(+), 3 deletions(-)

--- a/arch/sparc/include/asm/pgtable_64.h
+++ b/arch/sparc/include/asm/pgtable_64.h
@@ -24,7 +24,8 @@
 
 /* The kernel image occupies 0x4000000 to 0x6000000 (4MB --> 96MB).
  * The page copy blockops can use 0x6000000 to 0x8000000.
- * The TSB is mapped in the 0x8000000 to 0xa000000 range.
+ * The 8K TSB is mapped in the 0x8000000 to 0x8400000 range.
+ * The 4M TSB is mapped in the 0x8400000 to 0x8800000 range.
  * The PROM resides in an area spanning 0xf0000000 to 0x100000000.
  * The vmalloc area spans 0x100000000 to 0x200000000.
  * Since modules need to be in the lowest 32-bits of the address space,
@@ -33,7 +34,8 @@
  * 0x400000000.
  */
 #define	TLBTEMP_BASE		_AC(0x0000000006000000,UL)
-#define	TSBMAP_BASE		_AC(0x0000000008000000,UL)
+#define	TSBMAP_8K_BASE		_AC(0x0000000008000000,UL)
+#define	TSBMAP_4M_BASE		_AC(0x0000000008400000,UL)
 #define MODULES_VADDR		_AC(0x0000000010000000,UL)
 #define MODULES_LEN		_AC(0x00000000e0000000,UL)
 #define MODULES_END		_AC(0x00000000f0000000,UL)
--- a/arch/sparc/mm/tsb.c
+++ b/arch/sparc/mm/tsb.c
@@ -133,7 +133,19 @@ static void setup_tsb_params(struct mm_s
 	mm->context.tsb_block[tsb_idx].tsb_nentries =
 		tsb_bytes / sizeof(struct tsb);
 
-	base = TSBMAP_BASE;
+	switch (tsb_idx) {
+	case MM_TSB_BASE:
+		base = TSBMAP_8K_BASE;
+		break;
+#if defined(CONFIG_HUGETLB_PAGE) || defined(CONFIG_TRANSPARENT_HUGEPAGE)
+	case MM_TSB_HUGE:
+		base = TSBMAP_4M_BASE;
+		break;
+#endif
+	default:
+		BUG();
+	}
+
 	tte = pgprot_val(PAGE_KERNEL_LOCKED);
 	tsb_paddr = __pa(mm->context.tsb_block[tsb_idx].tsb);
 	BUG_ON(tsb_paddr & (tsb_bytes - 1UL));


Patches currently in stable-queue which might be from davem@xxxxxxxxxxxxx are

queue-3.10/sctp-fix-possible-seqlock-seadlock-in-sctp_packet_transmit.patch
queue-3.10/net-sendmsg-fix-null-pointer-dereference.patch
queue-3.10/sparc64-ldc_connect-should-not-return-einval-when-handshake-is-in-progress.patch
queue-3.10/sparc64-do-not-insert-non-valid-ptes-into-the-tsb-hash-table.patch
queue-3.10/iovec-make-sure-the-caller-actually-wants-anything-in-memcpy_fromiovecend.patch
queue-3.10/sparc64-don-t-bark-so-loudly-about-32-bit-tasks-generating-64-bit-fault-addresses.patch
queue-3.10/sparc64-fix-argument-sign-extension-for-compat_sys_futex.patch
queue-3.10/arch-sparc-math-emu-math_32.c-drop-stray-break-operator.patch
queue-3.10/net-correctly-set-segment-mac_len-in-skb_segment.patch
queue-3.10/ip-make-ip-identifiers-less-predictable.patch
queue-3.10/sparc64-fix-top-level-fault-handling-bugs.patch
queue-3.10/sparc64-fix-huge-tsb-mapping-on-pre-ultrasparc-iii-cpus.patch
queue-3.10/bnx2x-fix-crash-during-tso-tunneling.patch
queue-3.10/sparc64-make-itc_sync_lock-raw.patch
queue-3.10/bbc-i2c-fix-bbc-i2c-envctrl-on-sunblade-2000.patch
queue-3.10/sparc64-handle-32-bit-tasks-properly-in-compute_effective_address.patch
queue-3.10/sunsab-fix-detection-of-break-on-sunsab-serial-console.patch
queue-3.10/net-sctp-inherit-auth_capable-on-init-collisions.patch
queue-3.10/macvlan-initialize-vlan_features-to-turn-on-offload-support.patch
queue-3.10/tcp-fix-integer-overflow-in-tcp-vegas.patch
queue-3.10/inetpeer-get-rid-of-ip_id_count.patch
queue-3.10/sparc64-add-membar-to-niagara2-memcpy-code.patch
queue-3.10/sparc64-guard-against-flushing-openfirmware-mappings.patch
queue-3.10/tcp-fix-integer-overflows-in-tcp-veno.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]