Re: [patch] x86, mm: avoid stale tlb entries by clearing prev mm_cpumask after switching mm

[Suresh Siddha <suresh.b.siddha@intel.com>]

On Thu, 2011-02-03 at 11:48 -0800, Linus Torvalds wrote:
> On Thu, Feb 3, 2011 at 11:34 AM, Suresh Siddha
> <suresh.b.siddha@intel.com> wrote:
> >
> > True. 'stale' is the wrong word. Do you want me to send a corrected one
> > by replacing it with 'bogus'?
> 
> Please.
> 
> > my understanding is that unless we end up using that TLB entry, we will
> > not have the issues like machine checks due to cacheability issues etc.
> > If it is not global, upcoming cr3 change will flush it and meanwhile I
> > don't think there is a scenario where we refer to these user-addresses.
> 
> Quite possible. The situation I envisioned was the same speculative
> memory access that causes the TLB fill to also cause a cache fill -
> for a noncacheable region (because the bogus TLB entry sets the random
> address to cacheable).
> 
> And then what happens when somebody else accesses the same memory
> noncacheably (through a valid TLB entry), and finds it in the cache?
> 
> I dunno. Not really important. The important part is the "possible
> random bogus TLB entry", the fact that the CPU can act strangely after
> that is pretty much a given.
> 

Ok. Updated patch appended.

thanks,
suresh
---

From: Suresh Siddha <suresh.b.siddha@intel.com>
Subject: x86, mm: avoid bogus tlb entries by clearing prev mm_cpumask after switching mm

Clearing the cpu in prev's mm_cpumask early will avoid the flush tlb IPI's while
the cr3 is still pointing to the prev mm. And this window can lead
to the possibility of bogus TLB fills resulting in strange failures.
One such problematic scenario is mentioned below.

T1. CPU-1 is context switching from mm1 to mm2 context and got a NMI etc
between the point of clearing the cpu from the mm_cpumask(mm1) and before
reloading the cr3 with the new mm2.

T2. CPU-2 is tearing down a specific vma for mm1 and will proceed with flushing
the TLB for mm1. It doesn't send the flush TLB to CPU-1 as it doesn't see that
cpu listed in the mm_cpumask(mm1).

T3. After the TLB flush is complete, CPU-2 goes ahead and frees the
page-table pages associated with the removed vma mapping.

T4. CPU-2 now allocates those freed page-table pages for something else.

T5. As the CR3 and TLB caches for mm1 is still active on CPU-1, CPU-1 can
potentially speculate and walk through the page-table caches and can
insert new TLB entries. As the page-table pages are already freed and being
used on CPU-2, this page walk can potentially insert a bogus global TLB entry 
depending on the (random) contents of the page that is being used on CPU-2.

T6. This bogus TLB entry being global will be active across future CR3
changes and can result in weird memory corruption etc.

To avoid this issue, for the prev mm that is handing over the cpu to another mm,
clear the cpu from the mm_cpumask(prev) after the cr3 is changed.

Marking it for -stable, though we haven't seen any reported failure that
can be attributed to this.

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: stable@kernel.org	[v2.6.32+]
---
 arch/x86/include/asm/mmu_context.h |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/mmu_context.h b/arch/x86/include/asm/mmu_context.h
index 4a2d4e0..8b5393e 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -36,8 +36,6 @@ static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
 	unsigned cpu = smp_processor_id();
 
 	if (likely(prev != next)) {
-		/* stop flush ipis for the previous mm */
-		cpumask_clear_cpu(cpu, mm_cpumask(prev));
 #ifdef CONFIG_SMP
 		percpu_write(cpu_tlbstate.state, TLBSTATE_OK);
 		percpu_write(cpu_tlbstate.active_mm, next);
@@ -47,6 +45,9 @@ static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
 		/* Re-load page tables */
 		load_cr3(next->pgd);
 
+		/* stop flush ipis for the previous mm */
+		cpumask_clear_cpu(cpu, mm_cpumask(prev));
+
 		/*
 		 * load the LDT, if the LDT is different:
 		 */