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: Thu, 09 Aug 2007 15:24:40 -0400 From: Chris Snook <csnook@...hat.com> To: paulmck@...ux.vnet.ibm.com CC: linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org, torvalds@...ux-foundation.org, netdev@...r.kernel.org, akpm@...ux-foundation.org, ak@...e.de, heiko.carstens@...ibm.com, 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 Subject: Re: [PATCH 1/24] make atomic_read() behave consistently on alpha Paul E. McKenney wrote: > On Thu, Aug 09, 2007 at 02:13:52PM -0400, Chris Snook wrote: >> Paul E. McKenney wrote: >>> On Thu, Aug 09, 2007 at 01:14:35PM -0400, Chris Snook wrote: >>>> If you're depending on volatile writes >>>> being visible to other CPUs, you're screwed either way, because the CPU >>>> can hold that data in cache as long as it wants before it writes it to >>>> memory. When this finally does happen, it will happen atomically, which >>>> is all that atomic_set guarantees. If you need to guarantee that the >>>> value is written to memory at a particular time in your execution >>>> sequence, you either have to read it from memory to force the compiler to >>>> store it first (and a volatile cast in atomic_read will suffice for this) >>>> or you have to use LOCK_PREFIX instructions which will invalidate remote >>>> cache lines containing the same variable. This patch doesn't change >>>> either of these cases. >>> The case that it -can- change is interactions with interrupt handlers. >>> And NMI/SMI handlers, for that matter. >> You have a point here, but only if you can guarantee that the interrupt >> handler is running on a processor sharing the cache that has the >> not-yet-written volatile value. That implies a strictly non-SMP >> architecture. At the moment, none of those have volatile in their >> declaration of atomic_t, so this patch can't break any of them. > > This can also happen when using per-CPU variables. And there are a > number of per-CPU variables that are either atomic themselves or are > structures containing atomic fields. Accessing per-CPU variables in this fashion reliably already requires a suitable smp/non-smp read/write memory barrier. I maintain that if we break anything with this change, it was really already broken, if less obviously. Can you give a real or synthetic example of legitimate code that could break? -- Chris - 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