linux-kernel - Re: [patch 134/149] x86, paravirt: Add a global synchronization point for pvclock

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C3DF447.1000801@zytor.com>
Date:	Wed, 14 Jul 2010 10:30:47 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Peter Palfrader <peter@...frader.org>,
	Avi Kivity <avi@...hat.com>, Greg KH <gregkh@...e.de>,
	linux-kernel@...r.kernel.org, stable@...nel.org,
	stable-review@...nel.org, akpm@...ux-foundation.org,
	alan@...rguk.ukuu.org.uk, Glauber Costa <glommer@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>,
	Marcelo Tosatti <mtosatti@...hat.com>
Subject: Re: [patch 134/149] x86, paravirt: Add a global synchronization point
 	for pvclock

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/