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:	Mon, 20 Dec 2010 17:10:20 -0500 (EST)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Stephen Boyd <sboyd@...eaurora.org>
cc:	Arnaud Lacombe <lacombar@...il.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	lkml <linux-kernel@...r.kernel.org>,
	linux-arm-msm@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Tony Lindgren <tony@...mide.com>,
	Arnd Bergmann <arnd@...db.de>,
	Daniel Walker <dwalker@...eaurora.org>
Subject: Re: [PATCH 1/3] hvc_dcc: Fix bad code generation by marking assembly
 volatile

On Mon, 20 Dec 2010, Stephen Boyd wrote:

> On 12/20/2010 01:49 PM, Arnaud Lacombe wrote:
> > Hi,
> >
> > On Mon, Dec 20, 2010 at 3:08 PM, Stephen Boyd <sboyd@...eaurora.org> wrote:
> >> Without marking the asm __dcc_getstatus() volatile my compiler
> >> decides [...]
> > What compiler ? That might be a usefull information to know,
> > espectially 5 years from now when tracing code history. There has been
> > similar issue with gcc 4.5 recently. AFAIK, in the same idea, the
> > final change has been to mark the asm volatile.
> 
> Sure, we can replace "my compiler" with "my compiler (arm-eabi-gcc (GCC)
> 4.4.0)".

Compiler version doesn't matter -- this is a simple correctness issue.

If an inline asm statement provides an output value then the compiler is 
free to cache that value in a register, unless the inline asm is marked 
so that the value may change from one invocation to another.  Also, the 
compiler is free to eliminate the inline asm statement entirely as well 
if the output value provided by that inline asm is never used... unless 
if the inline asm is marked as having side effects.  In both cases the 
volatile qualifier does indicate that the returned value may change 
(new status flag state) and 
that the asm code therein has side effects (e.g. pop a character off a 
FIFO).

Sometimes the desired effect can be indicated by clever usage of 
parameter constraints, but in this case the volatile keyword is most 
appropriate.


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