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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 10 Sep 2007 16:44:31 -0700 From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> To: Chris Snook <csnook@...hat.com> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Denys Vlasenko <vda.linux@...glemail.com>, Kyle Moffett <mrmacman_g4@....com>, Arjan van de Ven <arjan@...radead.org>, Nick Piggin <piggin@...erone.com.au>, Satyam Sharma <satyam@...radead.org>, Herbert Xu <herbert@...dor.apana.org.au>, Paul Mackerras <paulus@...ba.org>, Christoph Lameter <clameter@....com>, Ilpo Jarvinen <ilpo.jarvinen@...sinki.fi>, Stefan Richter <stefanr@...6.in-berlin.de>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-arch@...r.kernel.org, Netdev <netdev@...r.kernel.org>, Andrew Morton <akpm@...ux-foundation.org>, ak@...e.de, heiko.carstens@...ibm.com, David Miller <davem@...emloft.net>, schwidefsky@...ibm.com, wensong@...ux-vs.org, horms@...ge.net.au, wjiang@...ilience.com, cfriesen@...tel.com, zlynx@....org, rpjday@...dspring.com, jesper.juhl@...il.com, segher@...nel.crashing.org Subject: Re: [PATCH] Document non-semantics of atomic_read() and atomic_set() On Mon, Sep 10, 2007 at 07:19:44PM -0400, Chris Snook wrote: > From: Chris Snook <csnook@...hat.com> > > Unambiguously document the fact that atomic_read() and atomic_set() > do not imply any ordering or memory access, and that callers are > obligated to explicitly invoke barriers as needed to ensure that > changes to atomic variables are visible in all contexts that need > to see them. Acked-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com> > Signed-off-by: Chris Snook <csnook@...hat.com> > > --- a/Documentation/atomic_ops.txt 2007-07-08 19:32:17.000000000 -0400 > +++ b/Documentation/atomic_ops.txt 2007-09-10 19:02:50.000000000 -0400 > @@ -12,7 +12,11 @@ > C integer type will fail. Something like the following should > suffice: > > - typedef struct { volatile int counter; } atomic_t; > + typedef struct { int counter; } atomic_t; > + > + Historically, counter has been declared volatile. This is now > +discouraged. See Documentation/volatile-considered-harmful.txt for the > +complete rationale. > > The first operations to implement for atomic_t's are the > initializers and plain reads. > @@ -42,6 +46,22 @@ > > which simply reads the current value of the counter. > > +*** WARNING: atomic_read() and atomic_set() DO NOT IMPLY BARRIERS! *** > + > +Some architectures may choose to use the volatile keyword, barriers, or > +inline assembly to guarantee some degree of immediacy for atomic_read() > +and atomic_set(). This is not uniformly guaranteed, and may change in > +the future, so all users of atomic_t should treat atomic_read() and > +atomic_set() as simple C assignment statements that may be reordered or > +optimized away entirely by the compiler or processor, and explicitly > +invoke the appropriate compiler and/or memory barrier for each use case. > +Failure to do so will result in code that may suddenly break when used with > +different architectures or compiler optimizations, or even changes in > +unrelated code which changes how the compiler optimizes the section > +accessing atomic_t variables. > + > +*** YOU HAVE BEEN WARNED! *** > + > Now, we move onto the actual atomic operation interfaces. > > void atomic_add(int i, atomic_t *v); - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists