linux-kernel - [PATCH 0/8] x86/mm/cpa: Further optimizations

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: <3c91a770-566c-5ac0-b899-18bc4e339e4e@intel.com>
Date:   Fri, 21 Sep 2018 15:50:23 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org,
        Bin Yang <bin.yang@...el.com>,
        Mark Gross <mark.gross@...el.com>
Subject: [PATCH 0/8] x86/mm/cpa: Further optimizations

On 09/19/2018 01:50 AM, Peter Zijlstra wrote:
> Dave, can you have a wee look at the Atom errata thing; this does grow the
> amount of code between the page-table update and the TLB flush a bit, but all
> that PTI crud we did a while back already made it a non-trivial amount of code.

Oh, were you worried that the act of sending the IPIs widens the window
vs. just doing the local flush?  We definitely do the
smp_call_function() dance *before* we do the local TLB invalidation in
in on_each_cpu().

But, the existing flush was not a "true" fix anyway.  It just tended to
work around things.

If the issue pops back up, I'd prefer that we just do:

	__flush_tlb_all();
	flush_tlb_all();

Preferably with an actual model/family check for the "AAH41" workaround.
 The real value of what you did was moving the flush_tlb_all() closer,
and that remains either way.