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
| ||
|
Date: Fri, 17 Aug 2007 11:56:22 +0530 (IST) From: Satyam Sharma <satyam@...radead.org> To: Herbert Xu <herbert@...dor.apana.org.au> cc: Paul Mackerras <paulus@...ba.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Christoph Lameter <clameter@....com>, Chris Snook <csnook@...hat.com>, Ilpo Jarvinen <ilpo.jarvinen@...sinki.fi>, "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, 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 0/24] make atomic_read() behave consistently across all architectures On Fri, 17 Aug 2007, Herbert Xu wrote: > On Fri, Aug 17, 2007 at 01:43:27PM +1000, Paul Mackerras wrote: > > > > The cost of doing so seems to me to be well down in the noise - 44 > > bytes of extra kernel text on a ppc64 G5 config, and I don't believe > > the extra few cycles for the occasional extra load would be measurable > > (they should all hit in the L1 dcache). I don't mind if x86[-64] have > > atomic_read/set be nonvolatile and find all the missing barriers, but > > for now on powerpc, I think that not having to find those missing > > barriers is worth the 0.00076% increase in kernel text size. > > BTW, the sort of missing barriers that triggered this thread > aren't that subtle. It'll result in a simple lock-up if the > loop condition holds upon entry. At which point it's fairly > straightforward to find the culprit. Not necessarily. A barrier-less buggy code such as below: atomic_set(&v, 0); ... /* some initial code */ while (atomic_read(&v)) ; ... /* code that MUST NOT be executed unless v becomes non-zero */ (where v->counter is has no volatile access semantics) could be generated by the compiler to simply *elid* or *do away* with the loop itself, thereby making the: "/* code that MUST NOT be executed unless v becomes non-zero */" to be executed even when v is zero! That is subtle indeed, and causes no hard lockups. Granted, the above IS buggy code. But, the stated objective is to avoid heisenbugs. And we have driver / subsystem maintainers such as Stefan coming up and admitting that often a lot of code that's written to use atomic_read() does assume the read will not be elided by the compiler. See, I agree, "volatility" semantics != what we often want. However, if what we want is compiler barrier, for only the object under consideration, "volatility" semantics aren't really "nonsensical" or anything. - 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