[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5be546b5-e34a-0bce-8cf5-b7c3f7ff28fe@mellanox.com>
Date: Fri, 9 Jun 2017 10:03:40 -0400
From: Chris Metcalf <cmetcalf@...lanox.com>
To: Peter Zijlstra <peterz@...radead.org>,
Will Deacon <will.deacon@....com>,
Paul McKenney <paulmck@...ux.vnet.ibm.com>,
Boqun Feng <boqun.feng@...il.com>
Cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>, vgupta@...opsys.com,
rkuo@...eaurora.org, james.hogan@...tec.com, jejb@...isc-linux.org,
davem@...emloft.net
Subject: Re: [RFC][PATCH] atomic: Fix atomic_set_release() for 'funny'
architectures
On 6/9/2017 7:05 AM, Peter Zijlstra wrote:
> Subject: atomic: Fix atomic_set_release() for 'funny' architectures
>
> Those architectures that have a special atomic_set implementation also
> need a special atomic_set_release(), because for the very same reason
> WRITE_ONCE() is broken for them, smp_store_release() is too.
>
> The vast majority is architectures that have spinlock hash based atomic
> implementation except hexagon which seems to have a hardware 'feature'.
>
> The spinlock based atomics should be SC, that is, none of them appear to
> place extra barriers in atomic_cmpxchg() or any of the other SC atomic
> primitives and therefore seem to rely on their spinlock implementation
> being SC (I did not fully validate all that).
>
> Therefore, the normal atomic_set() is SC and can be used at
> atomic_set_release().
Acked-by: Chris Metcalf <cmetcalf@...lanox.com> [for tile]
--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com
Powered by blists - more mailing lists