Re: [PATCH v2] arch: use WRITE_ONCE/READ_ONCE in smp_store_release/smp_load_acquire

2015-08-02 Thread Peter Zijlstra
On Sun, Aug 02, 2015 at 05:11:04PM +0200, Andrey Konovalov wrote: Replace ACCESS_ONCE() macro in smp_store_release() and smp_load_acquire() with WRITE_ONCE() and READ_ONCE() on x86, arm, arm64, ia64, metag, mips, powerpc, s390, sparc and asm-generic since ACCESS_ONCE does not work reliably on

Re: [PATCH v2 17/32] arm: define __smp_xxx

2016-01-04 Thread Peter Zijlstra
On Sun, Jan 03, 2016 at 11:12:44AM +0200, Michael S. Tsirkin wrote: > On Sat, Jan 02, 2016 at 11:24:38AM +, Russell King - ARM Linux wrote: > > My only concern is that it gives people an additional handle onto a > > "new" set of barriers - just because they're prefixed with __* > >

Re: [PATCH v2 06/32] s390: reuse asm-generic/barrier.h

2016-01-04 Thread Peter Zijlstra
On Thu, Dec 31, 2015 at 09:06:30PM +0200, Michael S. Tsirkin wrote: > On s390 read_barrier_depends, smp_read_barrier_depends > smp_store_mb(), smp_mb__before_atomic and smp_mb__after_atomic match the > asm-generic variants exactly. Drop the local definitions and pull in > asm-generic/barrier.h

Re: [PATCH v2 20/32] metag: define __smp_xxx

2016-01-04 Thread Peter Zijlstra
On Thu, Dec 31, 2015 at 09:08:22PM +0200, Michael S. Tsirkin wrote: > +#ifdef CONFIG_SMP > +#define fence() metag_fence() > +#else > +#define fence() do { } while (0) > #endif James, it strikes me as odd that fence() is a no-op instead of a barrier() for UP, can you verify/explain?

Re: [PATCH v2 31/32] sh: support a 2-byte smp_store_mb

2016-01-04 Thread Peter Zijlstra
On Thu, Dec 31, 2015 at 09:09:47PM +0200, Michael S. Tsirkin wrote: > At the moment, xchg on sh only supports 4 and 1 byte values, so using it > from smp_store_mb means attempts to store a 2 byte value using this > macro fail. > > And happens to be exactly what virtio drivers want to do. > >

Re: [PATCH v2 33/34] xenbus: use virt_xxx barriers

2016-01-04 Thread Peter Zijlstra
On Thu, Dec 31, 2015 at 09:10:01PM +0200, Michael S. Tsirkin wrote: > drivers/xen/xenbus/xenbus_comms.c uses > full memory barriers to communicate with the other side. > > For guests compiled with CONFIG_SMP, smp_wmb and smp_mb > would be sufficient, so mb() and wmb() here are only needed if > a

Re: [PATCH v2 20/32] metag: define __smp_xxx

2016-01-04 Thread Peter Zijlstra
On Mon, Jan 04, 2016 at 03:25:58PM +, James Hogan wrote: > It is used along with the metag specific __global_lock1() (global > voluntary lock between hw threads) whenever a write is performed, and by > smp_mb/smp_rmb to try to catch other cases, but I've never been > confident this fixes every