metag: fix memory barriers
authorMikulas Patocka <mpatocka@redhat.com>
Thu, 8 May 2014 19:51:37 +0000 (15:51 -0400)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 7 Jun 2014 17:28:23 +0000 (10:28 -0700)
commit43f0630e513566750fb51df14b54f5b4b4f3f65f
treeb2741e6e67d045ee2a1f2607c92c43e8761d137b
parent1ed85d074da980973dfd184ffe22bd83aef98901
metag: fix memory barriers

commit 2425ce84026c385b73ae72039f90d042d49e0394 upstream.

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@redhat.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arch/metag/include/asm/barrier.h