linux-kernel - Re: [PATCH 4/7] x86,tlb: make lazy TLB mode lazier

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]

Message-ID: <1529687760.7898.200.camel@surriel.com>
Date:   Fri, 22 Jun 2018 13:16:00 -0400
From:   Rik van Riel <riel@...riel.com>
To:     Dave Hansen <dave.hansen@...ux.intel.com>,
        linux-kernel@...r.kernel.org
Cc:     x86@...nel.org, luto@...nel.org, mingo@...nel.org,
        tglx@...utronix.de, efault@....de, songliubraving@...com,
        kernel-team@...com
Subject: Re: [PATCH 4/7] x86,tlb: make lazy TLB mode lazier

On Fri, 2018-06-22 at 10:05 -0700, Dave Hansen wrote:
> On 06/20/2018 12:56 PM, Rik van Riel wrote:
> > This patch deals with that issue by introducing a third TLB state,
> > TLBSTATE_FLUSH, which causes %CR3 to be reloaded at the next
> > context
> > switch.
> 
> With PCIDs, do we need to be a bit more explicit about what kind of
> %CR3
> reload we have?  Because, with PCIDs, we do have non-TLB-flushing
> %CR3
> writes.

Probably not in this patch series, because switch_mm_irqs_off
calls choose_new_asid, which figures all of this out for us
already.

Specifically, it has this bit of code to figure out whether
we need a flush:

                *need_flush =
(this_cpu_read(cpu_tlbstate.ctxs[asid].tlb_gen) <
                               next_tlb_gen);

As long as we get the memory ordering right, we should be
able to rely on that to switch back from lazy to non-lazy
TLB mode.

-- 
All Rights Reversed.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)