linux-kernel - Re: [PATCH] Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}

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]

Date:   Wed, 24 Apr 2019 01:29:48 -0700
From:   "Paul E. McKenney" <paulmck@...ux.ibm.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Nicholas Piggin <npiggin@...il.com>,
        LKMM Maintainers -- Akira Yokosawa <akiyks@...il.com>,
        Andrea Parri <andrea.parri@...rulasolutions.com>,
        Boqun Feng <boqun.feng@...il.com>,
        David Howells <dhowells@...hat.com>,
        Daniel Lustig <dlustig@...dia.com>,
        Jade Alglave <j.alglave@....ac.uk>,
        Kernel development list <linux-kernel@...r.kernel.org>,
        Luc Maranget <luc.maranget@...ia.fr>,
        Alan Stern <stern@...land.harvard.edu>,
        Will Deacon <will.deacon@....com>
Subject: Re: [PATCH] Documentation: atomic_t.txt: Explain ordering provided
 by smp_mb__{before,after}_atomic()

On Tue, Apr 23, 2019 at 10:28:31PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 23, 2019 at 01:16:37PM -0700, Paul E. McKenney wrote:
> 
> > Agreed, but I thought that one of the ideas going forward was to get
> > rid of smp_mb__{before,after}_atomic().
> 
> It's not one I had considered.. I just wanted to get rid of this
> 'surprise' behaviour.

Ah, good point, your patch is in fact a midpoint between those two
positions.  Just to make sure I understand:

1.	Without your patch, smp_mb__{before,after}_atomic() orders
	only against the atomic itself.

2.	With your patch, smp_mb__{before,after}_atomic() orders against
	the atomic itself and the accesses on the other side of that
	atomic.  However, it does not order the atomic against the
	accesses on the other side of that atomic.

	Putting things between the smp_mb__{before,after}_atomic()
	and the atomic is in my opinion a bad idea, but in this case
	they are not necessarily ordered.

3.	Dispensing with smp_mb__{before,after}_atomic() would have
	void RMW atomics fully ordered, but I suspect that it results
	in ugly performance regressions.

Or am I still missing something?

							Thanx, Paul