On 08/05/14 20:51, 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 <[email protected]>
> Cc: [email protected]Applied for v3.15, thanks! Cheers James > > --- > arch/metag/include/asm/barrier.h | 3 +++ > 1 file changed, 3 insertions(+) > > Index: linux-3.15-rc4/arch/metag/include/asm/barrier.h > =================================================================== > --- linux-3.15-rc4.orig/arch/metag/include/asm/barrier.h 2014-05-08 > 16:23:17.000000000 +0200 > +++ linux-3.15-rc4/arch/metag/include/asm/barrier.h 2014-05-08 > 16:24:01.000000000 +0200 > @@ -15,6 +15,7 @@ static inline void wr_fence(void) > volatile int *flushptr = (volatile int *) LINSYSEVENT_WR_FENCE; > barrier(); > *flushptr = 0; > + barrier(); > } > > #else /* CONFIG_METAG_META21 */ > @@ -35,6 +36,7 @@ static inline void wr_fence(void) > *flushptr = 0; > *flushptr = 0; > *flushptr = 0; > + barrier(); > } > > #endif /* !CONFIG_METAG_META21 */ > @@ -68,6 +70,7 @@ static inline void fence(void) > volatile int *flushptr = (volatile int *) LINSYSEVENT_WR_ATOMIC_UNLOCK; > barrier(); > *flushptr = 0; > + barrier(); > } > #define smp_mb() fence() > #define smp_rmb() fence() >
signature.asc
Description: OpenPGP digital signature
