x86, paravirt: Add a global synchronization point for pvclock
in [Kernel]
|
From: Jeremy Fitzhardinge on 14 Jul 2010 13:40 On 07/14/2010 10:30 AM, H. Peter Anvin wrote: > If gcc ever starts reordering volatile operations, including "asm > volatile", the kernel will break, and will be unfixable. Just about > every single driver will break. All over the kernel we're explicitly or > implicitly making the assumption that volatile operations are strictly > ordered by the compiler with respect to each other. > Can you give an example? All the cases I've seen rely on the ordering properties of "memory" clobbers, which is sound. (And volatile variables are a completely unrelated issue, of course.) J -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 14 Jul 2010 13:40 On 07/14/2010 10:19 AM, Jeremy Fitzhardinge wrote: > On 07/13/2010 05:15 PM, Linus Torvalds wrote: >> The gcc documentation wrt inline asm's is totally worthless. Don't >> even bother quoting it - because the gcc people themselves have never >> cared. If the docs ever end up not matching what they want to do, they >> will just change the documentation. >> >> In other words, at least historically the docs are not in any way >> meaningful. They are not a "these are the semantics we guarantee", >> they are just random noise. As I mentioned, the docs historically just >> said something like "will not be moved significantly", and apparently >> they've been changed to be something else. > > Sure, I completely agree. At the moment the docs say "asm volatile > guarantees nothing", and we can work with that. So long as we don't > expect asm volatile to mean anything more (ie, magic semantics involving > reordering), everyone is happy. Except we do. > BTW, gcc 2.95's docs do mention "asm volatile" having an effect on > ordering, which is probably where the notion came from: "If you write an > `asm' instruction with no outputs, GNU CC [...] not delete the > instruction or move it outside of loops. [...] you should write the > `volatile' keyword to prevent future versions of GNU CC from moving the > instruction around within a core region". Lucky we never relied on > that, right? Right? If gcc ever starts reordering volatile operations, including "asm volatile", the kernel will break, and will be unfixable. Just about every single driver will break. All over the kernel we're explicitly or implicitly making the assumption that volatile operations are strictly ordered by the compiler with respect to each other. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 14 Jul 2010 13:50 On 07/14/2010 10:34 AM, Jeremy Fitzhardinge wrote: > On 07/14/2010 10:30 AM, H. Peter Anvin wrote: >> If gcc ever starts reordering volatile operations, including "asm >> volatile", the kernel will break, and will be unfixable. Just about >> every single driver will break. All over the kernel we're explicitly or >> implicitly making the assumption that volatile operations are strictly >> ordered by the compiler with respect to each other. > > Can you give an example? All the cases I've seen rely on the ordering > properties of "memory" clobbers, which is sound. (And volatile > variables are a completely unrelated issue, of course.) > I/O ports, for example. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jeremy Fitzhardinge on 14 Jul 2010 14:00 On 07/14/2010 10:45 AM, H. Peter Anvin wrote: > On 07/14/2010 10:34 AM, Jeremy Fitzhardinge wrote: > >> On 07/14/2010 10:30 AM, H. Peter Anvin wrote: >> >>> If gcc ever starts reordering volatile operations, including "asm >>> volatile", the kernel will break, and will be unfixable. Just about >>> every single driver will break. All over the kernel we're explicitly or >>> implicitly making the assumption that volatile operations are strictly >>> ordered by the compiler with respect to each other. >>> >> Can you give an example? All the cases I've seen rely on the ordering >> properties of "memory" clobbers, which is sound. (And volatile >> variables are a completely unrelated issue, of course.) >> >> > I/O ports, for example. > Yes, it looks like they should have memory barriers if we want them to be ordered with respect to normal writes; afaict "asm volatile" has never had strict ordering wrt memory ops. Anything else? J -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 14 Jul 2010 14:10
[Adding H.J. to the Cc: list] On 07/14/2010 10:57 AM, Jeremy Fitzhardinge wrote: >>> >> I/O ports, for example. >> > > Yes, it looks like they should have memory barriers if we want them to > be ordered with respect to normal writes; afaict "asm volatile" has > never had strict ordering wrt memory ops. > Noone has talked about strict ordering between volatiles and (non-volatile) memory ops in general. I have been talking about volatile to volatile ordering, and I thought I'd been very clear about that. H.J., we're having a debate about the actual semantics of "volatile", especially "asm volatile" in gcc. In particular, I believe that volatile operations should not be possible to reorder with regards to each other, and the kernel depends on that fact. -hpa P.S: gcc 4.4 seems to handle "const volatile" incorrectly, probably by applying CSE to those values. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |