On Thu, May 08, 2014 at 03:51:37PM -0400, Mikulas Patocka wrote:
> Volatile access doesn't really imply the compiler barrier. Volatile access
> is only ordered with respect to other volatile accesses, it isn't ordered
> with respect to general memory accesses. Gcc may reorder memory accesses
> around volatile access, as we can see in this simple example (if we
> compile it with optimization, both increments of *b will be collapsed to
> just one):
>
> void fn(volatile int *a, long *b)
> {
> (*b)++;
> *a = 10;
> (*b)++;
> }
>
> Consequently, we need the compiler barrier after a write to the volatile
> variable, to make sure that the compiler doesn't reorder the volatile
> write with something else.
>
> Signed-off-by: Mikulas Patocka <mpatocka@xxxxxxxxxx>
> Cc: stable@xxxxxxxxxxxxxxx
Acked-by: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Attachment:
pgp4VTRWO6c61.pgp
Description: PGP signature
