linux-kernel - Re: [RFC][PATCH 1/5] mm: Rework {set,clear,mm}_tlb_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: <20170801164414.GB12027@arm.com>
Date:   Tue, 1 Aug 2017 17:44:14 +0100
From:   Will Deacon <will.deacon@....com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        torvalds@...ux-foundation.org, oleg@...hat.com,
        paulmck@...ux.vnet.ibm.com, mpe@...erman.id.au, npiggin@...il.com,
        linux-kernel@...r.kernel.org, mingo@...nel.org,
        stern@...land.harvard.edu, Mel Gorman <mgorman@...e.de>,
        Rik van Riel <riel@...hat.com>
Subject: Re: [RFC][PATCH 1/5] mm: Rework {set,clear,mm}_tlb_flush_pending()

On Tue, Aug 01, 2017 at 06:39:03PM +0200, Peter Zijlstra wrote:
> Still this is all rather unsatisfactory. Either we should define
> flush_tlb*() to imply a barrier when its not a no-op (sparc64/ppc-hash)
> or simply make clear_tlb_flush_pending() an smp_store_release().
> 
> I prefer the latter option.
> 
> Opinions?

I prefer the latter option too, since I'd like to relax the arm64 TLB
flushing to have weaker barriers for the local case. Granted, that doesn't
break the NUMA migration code, but it would make the barrier semantics of
the TLB invalidation routines even more subtle if we were to define them
generally.

Will