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
