From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org, "David S. Miller" <davem@davemloft.net>
Subject: [PATCH 3.10 20/24] sparc64: Guard against flushing openfirmware mappings.
Date: Fri, 8 Aug 2014 14:35:13 -0700 [thread overview]
Message-ID: <20140808213336.255548316@linuxfoundation.org> (raw)
In-Reply-To: <20140808213335.421758947@linuxfoundation.org>
3.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: "David S. Miller" <davem@davemloft.net>
[ Upstream commit 4ca9a23765da3260058db3431faf5b4efd8cf926 ]
Based almost entirely upon a patch by Christopher Alexander Tobias
Schulze.
In commit db64fe02258f1507e13fe5212a989922323685ce ("mm: rewrite vmap
layer") lazy VMAP tlb flushing was added to the vmalloc layer. This
causes problems on sparc64.
Sparc64 has two VMAP mapped regions and they are not contiguous with
eachother. First we have the malloc mapping area, then another
unrelated region, then the vmalloc region.
This "another unrelated region" is where the firmware is mapped.
If the lazy TLB flushing logic in the vmalloc code triggers after
we've had both a module unload and a vfree or similar, it will pass an
address range that goes from somewhere inside the malloc region to
somewhere inside the vmalloc region, and thus covering the
openfirmware area entirely.
The sparc64 kernel learns about openfirmware's dynamic mappings in
this region early in the boot, and then services TLB misses in this
area. But openfirmware has some locked TLB entries which are not
mentioned in those dynamic mappings and we should thus not disturb
them.
These huge lazy TLB flush ranges causes those openfirmware locked TLB
entries to be removed, resulting in all kinds of problems including
hard hangs and crashes during reboot/reset.
Besides causing problems like this, such huge TLB flush ranges are
also incredibly inefficient. A plea has been made with the author of
the VMAP lazy TLB flushing code, but for now we'll put a safety guard
into our flush_tlb_kernel_range() implementation.
Since the implementation has become non-trivial, stop defining it as a
macro and instead make it a function in a C source file.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/sparc/include/asm/tlbflush_64.h | 12 ++----------
arch/sparc/mm/init_64.c | 23 +++++++++++++++++++++++
2 files changed, 25 insertions(+), 10 deletions(-)
--- a/arch/sparc/include/asm/tlbflush_64.h
+++ b/arch/sparc/include/asm/tlbflush_64.h
@@ -35,6 +35,8 @@ static inline void flush_tlb_range(struc
{
}
+void flush_tlb_kernel_range(unsigned long start, unsigned long end);
+
#define __HAVE_ARCH_ENTER_LAZY_MMU_MODE
extern void flush_tlb_pending(void);
@@ -49,11 +51,6 @@ extern void __flush_tlb_kernel_range(uns
#ifndef CONFIG_SMP
-#define flush_tlb_kernel_range(start,end) \
-do { flush_tsb_kernel_range(start,end); \
- __flush_tlb_kernel_range(start,end); \
-} while (0)
-
static inline void global_flush_tlb_page(struct mm_struct *mm, unsigned long vaddr)
{
__flush_tlb_page(CTX_HWBITS(mm->context), vaddr);
@@ -64,11 +61,6 @@ static inline void global_flush_tlb_page
extern void smp_flush_tlb_kernel_range(unsigned long start, unsigned long end);
extern void smp_flush_tlb_page(struct mm_struct *mm, unsigned long vaddr);
-#define flush_tlb_kernel_range(start, end) \
-do { flush_tsb_kernel_range(start,end); \
- smp_flush_tlb_kernel_range(start, end); \
-} while (0)
-
#define global_flush_tlb_page(mm, vaddr) \
smp_flush_tlb_page(mm, vaddr)
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -2768,3 +2768,26 @@ void hugetlb_setup(struct pt_regs *regs)
}
}
#endif
+
+#ifdef CONFIG_SMP
+#define do_flush_tlb_kernel_range smp_flush_tlb_kernel_range
+#else
+#define do_flush_tlb_kernel_range __flush_tlb_kernel_range
+#endif
+
+void flush_tlb_kernel_range(unsigned long start, unsigned long end)
+{
+ if (start < HI_OBP_ADDRESS && end > LOW_OBP_ADDRESS) {
+ if (start < LOW_OBP_ADDRESS) {
+ flush_tsb_kernel_range(start, LOW_OBP_ADDRESS);
+ do_flush_tlb_kernel_range(start, LOW_OBP_ADDRESS);
+ }
+ if (end > HI_OBP_ADDRESS) {
+ flush_tsb_kernel_range(end, HI_OBP_ADDRESS);
+ do_flush_tlb_kernel_range(end, HI_OBP_ADDRESS);
+ }
+ } else {
+ flush_tsb_kernel_range(start, end);
+ do_flush_tlb_kernel_range(start, end);
+ }
+}
next prev parent reply other threads:[~2014-08-08 22:06 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-08 21:34 [PATCH 3.10 00/24] 3.10.53-stable review Greg Kroah-Hartman
2014-08-08 21:34 ` [PATCH 3.10 01/24] bnx2x: fix crash during TSO tunneling Greg Kroah-Hartman
2014-08-08 21:34 ` [PATCH 3.10 02/24] inetpeer: get rid of ip_id_count Greg Kroah-Hartman
2014-08-08 21:34 ` [PATCH 3.10 03/24] ip: make IP identifiers less predictable Greg Kroah-Hartman
2014-08-08 21:34 ` [PATCH 3.10 04/24] net: sendmsg: fix NULL pointer dereference Greg Kroah-Hartman
2014-08-08 21:34 ` [PATCH 3.10 05/24] tcp: Fix integer-overflows in TCP veno Greg Kroah-Hartman
2014-08-08 21:34 ` [PATCH 3.10 06/24] tcp: Fix integer-overflow in TCP vegas Greg Kroah-Hartman
2014-08-08 21:35 ` [PATCH 3.10 07/24] net: sctp: inherit auth_capable on INIT collisions Greg Kroah-Hartman
2014-08-08 21:35 ` [PATCH 3.10 08/24] macvlan: Initialize vlan_features to turn on offload support Greg Kroah-Hartman
2014-08-08 21:35 ` [PATCH 3.10 09/24] net: Correctly set segment mac_len in skb_segment() Greg Kroah-Hartman
2014-08-08 21:35 ` [PATCH 3.10 10/24] iovec: make sure the caller actually wants anything in memcpy_fromiovecend Greg Kroah-Hartman
2014-08-08 21:35 ` [PATCH 3.10 11/24] sctp: fix possible seqlock seadlock in sctp_packet_transmit() Greg Kroah-Hartman
2014-08-08 21:35 ` [PATCH 3.10 12/24] sparc64: Fix argument sign extension for compat_sys_futex() Greg Kroah-Hartman
2014-08-08 21:35 ` [PATCH 3.10 13/24] sparc64: Make itc_sync_lock raw Greg Kroah-Hartman
2014-08-08 21:35 ` [PATCH 3.10 14/24] sparc64: Handle 32-bit tasks properly in compute_effective_address() Greg Kroah-Hartman
2014-08-08 21:35 ` [PATCH 3.10 15/24] sparc64: Fix top-level fault handling bugs Greg Kroah-Hartman
2014-08-08 21:35 ` [PATCH 3.10 16/24] sparc64: Dont bark so loudly about 32-bit tasks generating 64-bit fault addresses Greg Kroah-Hartman
2014-08-08 21:35 ` [PATCH 3.10 17/24] sparc64: Fix huge TSB mapping on pre-UltraSPARC-III cpus Greg Kroah-Hartman
2014-08-08 21:35 ` [PATCH 3.10 18/24] sparc64: Add membar to Niagara2 memcpy code Greg Kroah-Hartman
2014-08-08 21:35 ` [PATCH 3.10 19/24] sparc64: Do not insert non-valid PTEs into the TSB hash table Greg Kroah-Hartman
2014-08-08 21:35 ` Greg Kroah-Hartman [this message]
2014-08-08 21:35 ` [PATCH 3.10 21/24] bbc-i2c: Fix BBC I2C envctrl on SunBlade 2000 Greg Kroah-Hartman
2014-08-08 21:35 ` [PATCH 3.10 22/24] sunsab: Fix detection of BREAK on sunsab serial console Greg Kroah-Hartman
2014-08-08 21:35 ` [PATCH 3.10 23/24] sparc64: ldc_connect() should not return EINVAL when handshake is in progress Greg Kroah-Hartman
2014-08-08 21:35 ` [PATCH 3.10 24/24] arch/sparc/math-emu/math_32.c: drop stray break operator Greg Kroah-Hartman
2014-08-09 1:03 ` [PATCH 3.10 00/24] 3.10.53-stable review Guenter Roeck
2014-08-09 14:41 ` Shuah Khan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140808213336.255548316@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).