linux-kernel - Re: [RFC][PATCH 0/5] arch: atomic rework

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 26 Feb 2014 18:43:44 +0000
From:	"Joseph S. Myers" <joseph@...esourcery.com>
To:	Torvald Riegel <triegel@...hat.com>
CC:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Michael Matz <matz@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Will Deacon <will.deacon@....com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ramana Radhakrishnan <Ramana.Radhakrishnan@....com>,
	David Howells <dhowells@...hat.com>,
	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"mingo@...nel.org" <mingo@...nel.org>,
	"gcc@....gnu.org" <gcc@....gnu.org>
Subject: Re: [RFC][PATCH 0/5] arch: atomic rework

On Wed, 26 Feb 2014, Torvald Riegel wrote:

> On Fri, 2014-02-21 at 22:10 +0000, Joseph S. Myers wrote:
> > On Fri, 21 Feb 2014, Paul E. McKenney wrote:
> > 
> > > This needs to be as follows:
> > > 
> > > [[carries_dependency]] int getzero(int i [[carries_dependency]])
> > > {
> > > 	return i - i;
> > > }
> > > 
> > > Otherwise dependencies won't get carried through it.
> > 
> > C11 doesn't have attributes at all (and no specification regarding calls 
> > and dependencies that I can see).  And the way I read the C++11 
> > specification of carries_dependency is that specifying carries_dependency 
> > is purely about increasing optimization of the caller: that if it isn't 
> > specified, then the caller doesn't know what dependencies might be 
> > carried.  "Note: The carries_dependency attribute does not change the 
> > meaning of the program, but may result in generation of more efficient 
> > code. - end note".
> 
> I think that this last sentence can be kind of misleading, especially
> when looking at it from an implementation point of view.  How
> dependencies are handled (ie, preserving the syntactic dependencies vs.
> emitting barriers) must be part of the ABI, or things like
> [[carries_dependency]] won't work as expected (or lead to inefficient
> code).  Thus, in practice, all compiler vendors on a platform would have
> to agree to a particular handling, which might end up in selecting the
> easy-but-conservative implementation option (ie, always emitting
> mo_acquire when the source uses mo_consume).

Regardless of the ABI, my point is that if a program is valid, it is also 
valid when all uses of [[carries_dependency]] are removed.  If a function 
doesn't use [[carries_dependency]], that means "dependencies may or may 
not be carried through this function".  If a function uses 
[[carries_dependency]], that means that certain dependencies *are* carried 
through the function (and the ABI should then specify what this means the 
caller can rely on, in terms of the architecture's memory model).  (This 
may or may not be useful, but it's how I understand C++11.)

-- 
Joseph S. Myers
joseph@...esourcery.com
--
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/