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: <20160220021516.4898897.32908.5212@gmail.com>
Date:	Fri, 19 Feb 2016 21:15:16 -0500
From:	Tony V E <tvaneerd@...il.com>
To:	"Paul E. McKenney" <parallel@...ts.isocpp.org>,
	parallel@...ts.isocpp.org, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, gcc@....gnu.org,
	llvm-dev@...ts.llvm.org
Cc:	peterz@...radead.org, j.alglave@....ac.uk, will.deacon@....com,
	dhowells@...hat.com, Ramana.Radhakrishnan@....com,
	luc.maranget@...ia.fr, akpm@...ux-foundation.org,
	Peter.Sewell@...cam.ac.uk, torvalds@...ux-foundation.org,
	mingo@...nel.org
Subject: Re: [isocpp-parallel] Proposal for new memory_order_consume definition

There's at least one easy answer in there:

> ‎If implementations must support annotation, what form should that
	annotation take?  P0190R0 recommends the [[carries_dependency]]
	attribute, but I am not picky as long as it can be (1) applied
	to all relevant pointer-like objects and (2) used in C as well
	as C++.  ;-)

If an implementation must support it, then it is not an annotation but a keyword. So no [[]] 



Sent from my BlackBerry portable Babbage Device
  Original Message  
From: Paul E. McKenney
Sent: Thursday, February 18, 2016 4:58 AM
To: parallel@...ts.isocpp.org; linux-kernel@...r.kernel.org; linux-arch@...r.kernel.org; gcc@....gnu.org; llvm-dev@...ts.llvm.org
Reply To: parallel@...ts.isocpp.org
Cc: peterz@...radead.org; j.alglave@....ac.uk; will.deacon@....com; dhowells@...hat.com; Ramana.Radhakrishnan@....com; luc.maranget@...ia.fr; akpm@...ux-foundation.org; Peter.Sewell@...cam.ac.uk; torvalds@...ux-foundation.org; mingo@...nel.org
Subject: [isocpp-parallel] Proposal for new memory_order_consume definition

Hello!

A proposal (quaintly identified as P0190R0) for a new memory_order_consume
definition may be found here:

http://www2.rdrop.com/users/paulmck/submission/consume.2016.02.10b.pdf

As requested at the October C++ Standards Committee meeting, this
is a follow-on to P0098R1 that picks one alternative and describes
it in detail. This approach focuses on existing practice, with the
goal of supporting existing code with existing compilers. In the last
clang/LLVM patch I saw for basic support of this change, you could count
the changed lines and still have lots of fingers and toes left over.
Those who have been following this story will recognize that this is
a very happy contrast to work that would be required to implement the
definition in the current standard.

I expect that P0190R0 will be discussed at the upcoming C++ Standards
Committee meeting taking place the week of February 29th. Points of
discussion are likely to include:

o	May memory_order_consume dependency ordering be used in
unannotated code? I believe that this must be the case,
especially given that this is our experience base. P0190R0
therefore recommends this approach.

o	If memory_order_consume dependency ordering can be used in
unannotated code, must implementations support annotation?
I believe that annotation support should be required, at the very
least for formal verification, which can be quite difficult to
carry out on unannotated code. In addition, it seems likely
that annotations can enable much better diagnostics. P0190R0
therefore recommends this approach.

o	If implementations must support annotation, what form should that
annotation take? P0190R0 recommends the [[carries_dependency]]
attribute, but I am not picky as long as it can be (1) applied
to all relevant pointer-like objects and (2) used in C as well
as C++. ;-)

o	If memory_order_consume dependency ordering can be used in
unannotated code, how best to define the situations where
the compiler can determine the exact value of the pointer in
question? (In current defacto implementations, this can
defeat dependency ordering. Interestingly enough, this case
is not present in the Linux kernel, but still needs to be
defined.)

Options include:

o	Provide new intrinsics that carry out the
comparisons, but guarantee to preserve dependencies,
as recommended by P0190R0 (std::pointer_cmp_eq_dep(),
std::pointer_cmp_ne_dep(), std::pointer_cmp_gt_dep(),
std::pointer_cmp_ge_dep(), std::pointer_cmp_lt_dep(),
and std::pointer_cmp_le_dep()).

o	State that -any- comparison involving an unannotated
pointer loses the dependency.

o	How is the common idiom of marking pointers by setting low-order
bits to be supported when those pointers carry dependencies?
At the moment, I believe that setting bits in pointers results in
undefined behavior even without dependency ordering, so P0190R0
kicks this particular can down the road. One option that
has been suggested is to provide intrinsics for this purpose.
(Sorry, but I forget who suggested this.)

Thoughts?

Thanx, Paul

_______________________________________________
Parallel mailing list
Parallel@...ts.isocpp.org
Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/parallel
Link to this post: http://lists.isocpp.org/parallel/2016/02/0040.php

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ