A-Team_Digital_Solutions/android_kernel_motorola_sm6375
Watch
2
0
Fork
You've already forked android_kernel_motorola_sm6375
 0
mirror of https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git synced 2026-10-28 02:32:09 -04:00
Code Issues Projects Releases Packages Wiki Activity

x86: revert "defer cr3 reload when doing pud_clear()"

Browse source 
Revert "defer cr3 reload when doing pud_clear()" since I'm going to
replace it.

Signed-off-by: Jeremy Fitzhardinge <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
This commit is contained in:
Jeremy Fitzhardinge 2008-02-04 16:48:02 +01:00 • committed by Ingo Molnar
commit a67ad9c9f8
2 changed files with 6 additions and 22 deletions
Download patch file Download diff file Expand all files Collapse all files

21
include/asm-x86/pgtable-3level.h
View file

@ -96,23 +96,14 @@ static inline void pud_clear(pud_t *pudp)
set_pud(pudp, __pud(0));
/*
* In principle we need to do a cr3 reload here to make sure
* the processor recognizes the changed pgd. In practice, all
* the places where pud_clear() gets called are followed by
* full tlb flushes anyway, so we can defer the cost here.
* Pentium-II erratum A13: in PAE mode we explicitly have to flush
* the TLB via cr3 if the top-level pgd is changed...
*
* Specifically:
*
* mm/memory.c:free_pmd_range() - immediately after the
* pud_clear() it does a pmd_free_tlb(). We change the
* mmu_gather structure to do a full tlb flush (which has the
* effect of reloading cr3) when the pagetable free is
* complete.
*
* arch/x86/mm/hugetlbpage.c:huge_pmd_unshare() - the call to
* this is followed by a flush_tlb_range, which on x86 does a
* full tlb flush.
* XXX I don't think we need to worry about this here, since
* when clearing the pud, the calling code needs to flush the
* tlb anyway. But do it now for safety's sake. - jsgf
*/
write_cr3(read_cr3());
}
#define pud_page(pud) \