linux-kernel - [PATCH] x86/mm: Don't flush the TLB on #WP pmd fixups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 20 Nov 2012 13:02:51 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Mel Gorman <mgorman@...e.de>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Turner <pjt@...gle.com>,
	Lee Schermerhorn <Lee.Schermerhorn@...com>,
	Christoph Lameter <cl@...ux.com>,
	Rik van Riel <riel@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Johannes Weiner <hannes@...xchg.org>,
	Hugh Dickins <hughd@...gle.com>
Subject: [PATCH] x86/mm: Don't flush the TLB on #WP pmd fixups


* Ingo Molnar <mingo@...nel.org> wrote:

> numa/core profile:
> 
>     95.66%  perf-1201.map     [.] 0x00007fe4ad1c8fc7                 
>      1.70%  libjvm.so         [.] 0x0000000000381581                 
>      0.59%  [vdso]            [.] 0x0000000000000607                 
>      0.19%  [kernel]          [k] do_raw_spin_lock                   
>      0.11%  [kernel]          [k] generic_smp_call_function_interrupt
>      0.11%  [kernel]          [k] timekeeping_get_ns.constprop.7     
>      0.08%  [kernel]          [k] ktime_get                          
>      0.06%  [kernel]          [k] get_cycles                         
>      0.05%  [kernel]          [k] __native_flush_tlb                 
>      0.05%  [kernel]          [k] rep_nop                            
>      0.04%  perf              [.] add_hist_entry.isra.9              
>      0.04%  [kernel]          [k] rcu_check_callbacks                
>      0.04%  [kernel]          [k] ktime_get_update_offsets           
>      0.04%  libc-2.15.so      [.] __strcmp_sse2                      
> 
> No page fault overhead (see the page fault rate further below) 
> - the NUMA scanning overhead shows up only through some mild 
> TLB flush activity (which I'll fix btw).

The patch attached below should get rid of that mild TLB 
flushing activity as well.

Thanks,

	Ingo

--------------------------->
Subject: x86/mm: Don't flush the TLB on #WP pmd fixups
From: Ingo Molnar <mingo@...nel.org>
Date: Tue Nov 20 14:46:34 CET 2012

If we have a write protection #PF and fix up the pmd then the
hugetlb code [the only user of pmdp_set_access_flags], in its
do_huge_pmd_wp_page() page fault resolution function calls
pmdp_set_access_flags() to mark the pmd permissive again,
and flushes the TLB.

This TLB flush is unnecessary: a flush on #PF is guaranteed on
most (all?) x86 CPUs, and even in the worst-case we'll generate
a spurious fault.

So remove it.

Cc: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: Andrea Arcangeli <aarcange@...hat.com>
Cc: Hugh Dickins <hughd@...gle.com>
Signed-off-by: Ingo Molnar <mingo@...nel.org>
---
 arch/x86/mm/pgtable.c |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

Index: linux/arch/x86/mm/pgtable.c
===================================================================
--- linux.orig/arch/x86/mm/pgtable.c
+++ linux/arch/x86/mm/pgtable.c
@@ -334,7 +334,12 @@ int pmdp_set_access_flags(struct vm_area
 	if (changed && dirty) {
 		*pmdp = entry;
 		pmd_update_defer(vma->vm_mm, address, pmdp);
-		flush_tlb_range(vma, address, address + HPAGE_PMD_SIZE);
+		/*
+		 * We had a write-protection fault here and changed the pmd
+		 * to to more permissive. No need to flush the TLB for that,
+		 * #PF is architecturally guaranteed to do that and in the
+		 * worst-case we'll generate a spurious fault.
+		 */
 	}
 
 	return changed;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/