Re: [PATCH] metag: fix memory barriers

[James Hogan]

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 <mpatocka@xxxxxxxxxx>
> Cc: stable@xxxxxxxxxxxxxxx

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()
>

Attachment: signature.asc
Description: OpenPGP digital signature