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 14:50:41 -0700 From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> To: Christoph Lameter <clameter@....com> Cc: Segher Boessenkool <segher@...nel.crashing.org>, Paul Mackerras <paulus@...ba.org>, heiko.carstens@...ibm.com, horms@...ge.net.au, Stefan Richter <stefanr@...6.in-berlin.de>, Satyam Sharma <satyam@...radead.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, David Miller <davem@...emloft.net>, Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>, ak@...e.de, cfriesen@...tel.com, rpjday@...dspring.com, Netdev <netdev@...r.kernel.org>, jesper.juhl@...il.com, linux-arch@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>, zlynx@....org, schwidefsky@...ibm.com, Chris Snook <csnook@...hat.com>, Herbert Xu <herbert@...dor.apana.org.au>, Linus Torvalds <torvalds@...ux-foundation.org>, wensong@...ux-vs.org, wjiang@...ilience.com Subject: Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures On Mon, Sep 10, 2007 at 02:36:26PM -0700, Christoph Lameter wrote: > On Mon, 10 Sep 2007, Paul E. McKenney wrote: > > > The one exception to this being the case where process-level code is > > communicating to an interrupt handler running on that same CPU -- on > > all CPUs that I am aware of, a given CPU always sees its own writes > > in order. > > Yes but that is due to the code path effectively continuing in the > interrupt handler. The cpu makes sure that op codes being executed always > see memory in a consistent way. The basic ordering problem with out of > order writes is therefore coming from other processors concurrently > executing code and holding variables in registers that are modified > elsewhere. The only solution that I know of are one or the other form of > barrier. So we are agreed then -- volatile accesses may be of some assistance when interacting with interrupt handlers running on the same CPU (presumably when using per-CPU variables), but are generally useless when sharing variables among CPUs. Correct? Thanx, Paul - 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