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]

Date:	Wed, 14 Jul 2010 14:11:03 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"H.J. Lu" <hjl.tools@...il.com>
CC:	"H. Peter Anvin" <hpa@...or.com>,
	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 12:40 PM, H.J. Lu wrote:
> On Wed, Jul 14, 2010 at 12:36 PM, H. Peter Anvin <hpa@...or.com> wrote:
>   
>> On 07/14/2010 12:32 PM, H.J. Lu wrote:
>>     
>>> On Wed, Jul 14, 2010 at 12:00 PM, H. Peter Anvin <hpa@...or.com> wrote:
>>>       
>>>> On 07/14/2010 11:18 AM, H.J. Lu wrote:
>>>>         
>>>>> There are some discussions on:
>>>>>
>>>>> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02001.html
>>>>> http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00001.html
>>>>>
>>>>> Are they related?
>>>>>
>>>>>           
>>>> Not directly as far as I can tell.
>>>>
>>>> The issue is if gcc can ever reorder, duplicate or elide a volatile
>>>> operation (either asm volatile or a volatile-annotated memory
>>>> reference.)  In my (and Linus') opinion, this would be an incredibly
>>>> serious bug.
>>>>         
>>> Is there a gcc bug for this?
>>>
>>>       
>> Are you asking for a bug report against the documentation?  We're not
>> sure what the semantics intended by the gcc team to be, which I guess is
>> a documentation bug.
>>
>>     
> Documentation bug is also a bug :-).
>   

The question is "what are the real ordering semantics of asm volatile"? 
What ordering is enforced between other asm volatiles?  What ordering is
enforced between asm volatiles and regular memory accesses? asm volatile
and other code?

The documentation discusses this to some extent, but mostly says "there
are no ordering guarantees".  Older versions of gcc - 2.95, for example
- are more explicit, saying that "asm volatiles" won't be moved out of
their basic block (I think that's how I parse it, anyway).

Linux relies on "asm volatile" being ordered at least with respect to
other asm volatiles.  Is this reasonable now?  Will gcc break this at
some point in the future?  If we can't rely on "asm volatile" ordering
semantics, what other mechanism can we use (for example, to order clts
with respect to FPU-using code)?

Thanks,
    J
--
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/