From: "Nikunj A. Dadhania" <nikunj@linux.vnet.ibm.com>
To: peterz@infradead.org, mtosatti@redhat.com, avi@redhat.com
Cc: raghukt@linux.vnet.ibm.com, alex.shi@intel.com, mingo@elte.hu,
kvm@vger.kernel.org, hpa@zytor.com
Subject: [PATCH v3 2/8] mm: Add missing TLB invalidate to RCU page-table freeing
Date: Tue, 31 Jul 2012 16:18:22 +0530 [thread overview]
Message-ID: <20120731104755.16662.16157.stgit@abhimanyu.in.ibm.com> (raw)
In-Reply-To: <20120731104312.16662.27889.stgit@abhimanyu.in.ibm.com>
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
For normal systems we need a TLB invalidate before freeing the
page-tables, the generic RCU based page-table freeing code lacked
this.
This is because this code originally came from ppc where the hardware
never walks the linux page-tables and thus this invalidate is not
required.
Others, notably s390 which ran into this problem in cd94154cc6a
("[S390] fix tlb flushing for page table pages"), do very much need
this TLB invalidation.
Therefore add it, with a Kconfig option to disable it so as to not
unduly slow down PPC and SPARC64 which neither of them need it.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/n/tip-z32nke0csqopykthsk1zjg8f@git.kernel.org
[Fix to check *batch is not NULL]
Signed-off-by: Nikunj A. Dadhania <nikunj@linux.vnet.ibm.com>
---
arch/Kconfig | 3 +++
arch/powerpc/Kconfig | 1 +
arch/sparc/Kconfig | 1 +
mm/memory.c | 43 +++++++++++++++++++++++++++++++++++++------
4 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index 8c3d957..fec1c9b 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -231,6 +231,9 @@ config HAVE_ARCH_MUTEX_CPU_RELAX
config HAVE_RCU_TABLE_FREE
bool
+config STRICT_TLB_FILL
+ bool
+
config ARCH_HAVE_NMI_SAFE_CMPXCHG
bool
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 9a5d3cd..fb70260 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -127,6 +127,7 @@ config PPC
select GENERIC_IRQ_SHOW_LEVEL
select IRQ_FORCED_THREADING
select HAVE_RCU_TABLE_FREE if SMP
+ select STRICT_TLB_FILL
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_BPF_JIT if PPC64
select HAVE_ARCH_JUMP_LABEL
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index e74ff13..126e500 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -52,6 +52,7 @@ config SPARC64
select HAVE_KRETPROBES
select HAVE_KPROBES
select HAVE_RCU_TABLE_FREE if SMP
+ select STRICT_TLB_FILL
select HAVE_MEMBLOCK
select HAVE_MEMBLOCK_NODE_MAP
select HAVE_SYSCALL_WRAPPERS
diff --git a/mm/memory.c b/mm/memory.c
index 91f6945..2ef9ce1 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -332,12 +332,47 @@ static void tlb_remove_table_rcu(struct rcu_head *head)
free_page((unsigned long)batch);
}
+#ifdef CONFIG_STRICT_TLB_FILL
+/*
+ * Some archictures (sparc64, ppc) cannot refill TLBs after the they've removed
+ * the PTE entries from their hash-table. Their hardware never looks at the
+ * linux page-table structures, so they don't need a hardware TLB invalidate
+ * when tearing down the page-table structure itself.
+ */
+static inline void tlb_table_flush_mmu(struct mmu_gather *tlb) { }
+
+/*
+ * When there's less than two users of this mm there cannot be
+ * a concurrent page-table walk.
+ */
+static inline bool tlb_table_fast(struct mmu_gather *tlb)
+{
+ return atomic_read(&tlb->mm->mm_users) < 2;
+}
+#else
+static inline void tlb_table_flush_mmu(struct mmu_gather *tlb)
+{
+ tlb_flush_mmu(tlb);
+}
+
+/*
+ * Even if there's only a single user, speculative TLB loads can
+ * wreck stuff.
+ */
+static inline bool tlb_table_fast(struct mmu_gather *tlb)
+{
+ return false;
+}
+#endif /* CONFIG_STRICT_TLB_FILL */
+
void tlb_table_flush(struct mmu_gather *tlb)
{
struct mmu_table_batch **batch = &tlb->batch;
if (*batch) {
- call_rcu_sched(&(*batch)->rcu, tlb_remove_table_rcu);
+ tlb_table_flush_mmu(tlb);
+ if (*batch)
+ call_rcu_sched(&(*batch)->rcu, tlb_remove_table_rcu);
*batch = NULL;
}
}
@@ -348,11 +383,7 @@ void tlb_remove_table(struct mmu_gather *tlb, void *table)
tlb->need_flush = 1;
- /*
- * When there's less then two users of this mm there cannot be a
- * concurrent page-table walk.
- */
- if (atomic_read(&tlb->mm->mm_users) < 2) {
+ if (tlb_table_fast(tlb)) {
__tlb_remove_table(table);
return;
}
next prev parent reply other threads:[~2012-07-31 10:49 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-31 10:47 [PATCH v3 0/8] KVM paravirt remote flush tlb Nikunj A. Dadhania
2012-07-31 10:47 ` [PATCH v3 1/8] mm, x86: Add HAVE_RCU_TABLE_FREE support Nikunj A. Dadhania
2012-07-31 10:48 ` Nikunj A. Dadhania [this message]
2012-07-31 10:48 ` [PATCH v3 3/8] KVM Guest: Add VCPU running/pre-empted state for guest Nikunj A. Dadhania
2012-07-31 10:48 ` [PATCH v3 4/8] KVM-HV: " Nikunj A. Dadhania
2012-08-02 19:56 ` Marcelo Tosatti
2012-08-03 5:17 ` Nikunj A Dadhania
2012-08-03 5:55 ` Nikunj A Dadhania
2012-08-03 17:31 ` Marcelo Tosatti
2012-08-04 18:33 ` Nikunj A Dadhania
2012-07-31 10:48 ` [PATCH v3 5/8] KVM Guest: Add paravirt kvm_flush_tlb_others Nikunj A. Dadhania
2012-07-31 10:49 ` [PATCH v3 6/8] KVM-HV: Add flush_on_enter before guest enter Nikunj A. Dadhania
2012-08-02 20:14 ` Marcelo Tosatti
2012-08-02 20:16 ` Marcelo Tosatti
2012-08-03 5:37 ` Nikunj A Dadhania
2012-08-03 17:31 ` Marcelo Tosatti
2012-07-31 10:49 ` [PATCH v3 7/8] Enable HAVE_RCU_TABLE_FREE for kvm when PARAVIRT_TLB_FLUSH is enabled Nikunj A. Dadhania
2012-07-31 10:49 ` [PATCH v3 8/8] KVM-doc: Add paravirt tlb flush document Nikunj A. Dadhania
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=20120731104755.16662.16157.stgit@abhimanyu.in.ibm.com \
--to=nikunj@linux.vnet.ibm.com \
--cc=alex.shi@intel.com \
--cc=avi@redhat.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mtosatti@redhat.com \
--cc=peterz@infradead.org \
--cc=raghukt@linux.vnet.ibm.com \
/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).