linux-kernel - Re: [PATCH v4 3/9] asm-generic/tlb: Avoid potential double flush

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20200116174626.0244f71bbff64eee6c7faa1d@linux-foundation.org>
Date:   Thu, 16 Jan 2020 17:46:26 -0800
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>
Cc:     peterz@...radead.org, will@...nel.org, mpe@...erman.id.au,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        linux-arch@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v4 3/9] asm-generic/tlb: Avoid potential double flush

On Thu, 16 Jan 2020 12:19:59 +0530 "Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com> wrote:

> On 1/16/20 12:15 PM, Aneesh Kumar K.V wrote:
> > From: Peter Zijlstra <peterz@...radead.org>
> > 
> > Aneesh reported that:
> > 
> > 	tlb_flush_mmu()
> > 	  tlb_flush_mmu_tlbonly()
> > 	    tlb_flush()			<-- #1
> > 	  tlb_flush_mmu_free()
> > 	    tlb_table_flush()
> > 	      tlb_table_invalidate()
> > 		tlb_flush_mmu_tlbonly()
> > 		  tlb_flush()		<-- #2
> > 
> > does two TLBIs when tlb->fullmm, because __tlb_reset_range() will not
> > clear tlb->end in that case.
> > 
> > Observe that any caller to __tlb_adjust_range() also sets at least one
> > of the tlb->freed_tables || tlb->cleared_p* bits, and those are
> > unconditionally cleared by __tlb_reset_range().
> > 
> > Change the condition for actually issuing TLBI to having one of those
> > bits set, as opposed to having tlb->end != 0.
> > 
> 
> 
> We should possibly get this to stable too along with the first two 
> patches. I am not quiet sure if this will qualify for a stable backport. 
> Hence avoided adding Cc:stable@...nel.org

I'm not seeing any description of the user-visible runtime effects. 
Always needed, especially for -stable, please.

It appears to be a small performance benefit?  If that benefit was
"large" and measurements were presented then that would be something
we might wish to backport.