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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 8 May 2007 15:35:31 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
cc:	Randy Dunlap <randy.dunlap@...cle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Paul Sokolovsky <pmiscml@...il.com>,
	linux-kernel@...r.kernel.org, Andi Kleen <ak@...e.de>
Subject: Re: [RFC/PATCH] doc: volatile considered evil

On Tue, 8 May 2007, Jeremy Fitzhardinge wrote:

> Sounds like it's referring to micro-architectural reordering, which is
> distinct from compiler reordering.  In other words, even if you
> specified "-mvolatile-asm-stop" I would assume that the compiler could
> still reorder the asm statements.  Am I right, or should I read more
> into the manual description than it actually says?
> 

The ia64 architecture does not include any interlocks for asm constructs 
and allow them to be executed in parallel without stop bits (although it 
should emit a diagnostic message from gcc, although that is not a 
constraint that was introduced in C99).  Adding -mvolatile-asm-stops will 
add these stop bits for any asm volatile construct that does not already 
have them so that gcc is aware that it is unsafe to execute such 
constructs in parallel.

 [ This is a tangent because we currently don't have -mvolatile-asm-stop
   support and it's ia64-specific.  If they ever request such support,
   then this will simply alter your warning about reordering asm
   volatile constructs to exclude the ia64 case. ]

		David
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ