linux-kernel - Re: [PATCH 3/3] membarrier: Propagate SYNC

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: <20201201185556.GV3040@hirez.programming.kicks-ass.net>
Date:   Tue, 1 Dec 2020 19:55:56 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     X86 ML <x86@...nel.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Nicholas Piggin <npiggin@...il.com>,
        Arnd Bergmann <arnd@...db.de>,
        Anton Blanchard <anton@...abs.org>
Subject: Re: [PATCH 3/3] membarrier: Propagate SYNC_CORE and RSEQ actions
 more carefully

On Tue, Dec 01, 2020 at 10:09:22AM -0800, Andy Lutomirski wrote:
> > smp_call_function_single(.wait=1) already orders against completion of
> > the IPI. Do we really need more?
> 
> What kind of order does it provide?  A quick skim of the code suggests
> that it's an acquire barrier, but I think we need a full sequential
> consistency barrier, at least on sufficiently weakly ordered
> architectures.  On x86, loads are ordered and this is probably
> irrelevant.  Also, this barrier was already there (it's the one I
> deleted below), and I think that removing it should be its own patch
> if we want to go that route.

	smp_mb()
	raise-IPI ---->
			<IPI>
			  /* do crud */
			  STORE-RELEASE csd->lock, 0;
			</IPI/

	LOAD-ACQUIRE csd->lock