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: <4640ED7D.708@goop.org>
Date:	Tue, 08 May 2007 14:37:01 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	David Rientjes <rientjes@...gle.com>
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

David Rientjes wrote:
> Ok, so let's take your second paragraph and my email of an hour ago:
>
> 	In an asm construct, if all your input operands are modified and 
> 	specified as output operands as well, volatile must be added so 
> 	that the entire construct is not optimized away.  Additionally, 
> 	it must be added if your construct modifies memory that is neither 
> 	listed in inputs nor outputs to the construct so that it is known 
> 	to have at least one side-effect.

Hm.  Is "asm volatile" necessary if you have a "memory" clobber?  Would
probably be the safest thing, I guess.

> and add it to any proposed change to CodingStyle that suggests against the 
> 'volatile' keyword since there exists a distinct difference in behavior 
> between using the keyword as a type qualifier for an object and as a 
> qualifier for an asm construct.
>   

Yeah, they're completely different.  They're not even analogous, really,
which was my point.  People confer more meaning to "asm volatile" than
it actually has, because of the analogy with volatile variables/types. 
They would have been better off with something like "asm static", which
isn't much more meaningful, but at least it doesn't mislead the reader
into thinking it has anything to do with the other volatile.

But yes, seems like a worthwhile thing to point out.  Or just point to
the gcc manual, which is pretty clear about all this stuff.

    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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ