linux-kernel - Re: [RFC/PATCH] doc: volatile considered evil

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:	Tue, 8 May 2007 14:59:45 -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:

> > 	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.
> 

No, because the first requirement for 'volatile' in my paragraph above is 
restricted to clobbering specific hard registers and an operand cannot 
describe a hard register for a member when that register appears in the 
clobber list.  If an input operand is modified (i.e. not "accessed", 
rather "modified" inclusive of the case where the previous value is the 
same as the original value) then it must also be specified as an output 
operand.

Now if all such output operands are to specify that the input operands 
were "modified", 'volatile' is required to ensure the side-effects are 
preserved or, otherwise, gcc is free optimize the entire asm construct 
away since it appears to be unused.

> 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.
> 

You're point about reordering "asm volatile" constructs differs depending 
on -mvolatile-asm-stop or -mno-volatile-asm-stop, however.

		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/