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]

Message-ID: <20150905175302.GV3644@twins.programming.kicks-ass.net>
Date:	Sat, 5 Sep 2015 19:53:02 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Chris Metcalf <cmetcalf@...hip.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Will Deacon <will.deacon@....com>,
	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>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Richard Henderson <rth@...ddle.net>
Subject: Re: futex atomic vs ordering constraints

On Wed, Sep 02, 2015 at 02:18:53PM -0700, Linus Torvalds wrote:
> So I think we could possibly relax the requirements (and document this
> very clearly) to say that the futex operation must be totally ordered
> wrt any other _user_space_ accesses by that thread. I suspect a lot of
> architectures can then say "we may be very weakly ordered, but kernel
> entry/exit implies enough synchronization that we do not need any
> futher memory barriers".

Right, so before sending this email I actually spoke to Ralf about this
option, and he said that this is not actually well defined for MIPS.

But we could certainly document it such and let archs for which this is
well documented (I would expect this to be most) choose that
implementation.


--
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/