linux-kernel - Re: futex atomic vs ordering constraints

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:	Tue, 1 Sep 2015 18:42:47 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Will Deacon <will.deacon@....com>
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...nel.org>,
	"mtk.manpages@...il.com" <mtk.manpages@...il.com>,
	"dvhart@...radead.org" <dvhart@...radead.org>,
	"dave@...olabs.net" <dave@...olabs.net>,
	"Vineet.Gupta1@...opsys.com" <Vineet.Gupta1@...opsys.com>,
	"ralf@...ux-mips.org" <ralf@...ux-mips.org>,
	"ddaney@...iumnetworks.com" <ddaney@...iumnetworks.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: futex atomic vs ordering constraints

On Tue, Sep 01, 2015 at 05:31:40PM +0100, Will Deacon wrote:
> Hi Peter,
> 
> On Wed, Aug 26, 2015 at 07:16:59PM +0100, Peter Zijlstra wrote:
> > I tried to keep this email short, but failed miserably at this. For
> > the TL;DR skip to the tail.
> 
> [...]
> 
> > There are a few options:
> > 
> >  1) punt, mandate they're both fully ordered and stop thinking about it
> > 
> >  2) make them both fully relaxed, rely on implied barriers and employ
> >     smp_mb__{before,after}_atomic in key places
> > 
> > Given the current state of things and that I don't really think there is
> > a compelling performance argument to be made for 2, I would suggest we
> > go with 1.
> 
> I'd also go for (1). Since there is a userspace side to this, I'd *really*
> like to avoid a potential situation on arm64 where the kernel builds its
> side of the futex using barrier instructions (e.g. treat LDR + smp_mb()
> as acquire) and userspace builds its side out of native acquire/release
> instructions and the two end up interacting badly (for example, loss of
> SC).

I thought your native acquire/release were RCsc, or is it that in
combination with the 'fancy' 'full' barrier of stlxr + dmb-ish something
goes sideways?

But yes, unless Thomas has other plans, I'll go ahead and create some
patches to make sure everybody is fully ordered so we can forget about
it again.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/