From: Rik van Riel <[email protected]>

If ptep_set_access_flags() is invoked to upgrade access permissions
on a PTE, there is no security or data integrity reason to do a
remote TLB flush.

Lazily letting another CPU incur a spurious page fault occasionally
is (much!) cheaper than aggressively flushing everybody else's TLB.

Signed-off-by: Rik van Riel <[email protected]>
Signed-off-by: Peter Zijlstra <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
 arch/x86/mm/pgtable.c |   17 ++++++++++++++++-
 1 file changed, 16 insertions(+), 1 deletion(-)

Index: tip/arch/x86/mm/pgtable.c
===================================================================
--- tip.orig/arch/x86/mm/pgtable.c
+++ tip/arch/x86/mm/pgtable.c
@@ -306,11 +306,26 @@ int ptep_set_access_flags(struct vm_area
                          pte_t entry, int dirty)
 {
        int changed = !pte_same(*ptep, entry);
+       /*
+        * If the page used to be inaccessible (_PAGE_PROTNONE), or
+        * this call upgrades the access permissions on the same page,
+        * it is safe to skip the remote TLB flush.
+        */
+       bool flush_remote = false;
+       if (!pte_accessible(*ptep))
+               flush_remote = false;
+       else if (pte_pfn(*ptep) != pte_pfn(entry) ||
+                       (pte_write(*ptep) && !pte_write(entry)) ||
+                       (pte_exec(*ptep) && !pte_exec(entry)))
+               flush_remote = true;
 
        if (changed && dirty) {
                *ptep = entry;
                pte_update_defer(vma->vm_mm, address, ptep);
-               flush_tlb_page(vma, address);
+               if (flush_remote)
+                       flush_tlb_page(vma, address);
+               else
+                       __flush_tlb_one(address);
        }
 
        return changed;


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to