search for: compiletime_assert_atomic_typ

On Fri, Nov 25, 2016 at 01:40:44PM +0100, Peter Zijlstra wrote: > #define SINGLE_LOAD(x) \ > {( \ > compiletime_assert_atomic_type(typeof(x)); \ Should be: compiletime_assert_atomic_type(x); > WARN_SINGLE_COPY_ALIGNMENT(&(x)); \ > READ_ONCE(x); \ > }) > > #define SINGLE_STORE(x, v) \ > ({ \ > compiletime_assert_atomic_type(typeof(x)); \ idem > WARN_SINGLE_COPY_ALIGNME...

On Fri, Nov 25, 2016 at 01:40:44PM +0100, Peter Zijlstra wrote: > #define SINGLE_LOAD(x) \ > {( \ > compiletime_assert_atomic_type(typeof(x)); \ Should be: compiletime_assert_atomic_type(x); > WARN_SINGLE_COPY_ALIGNMENT(&(x)); \ > READ_ONCE(x); \ > }) > > #define SINGLE_STORE(x, v) \ > ({ \ > compiletime_assert_atomic_type(typeof(x)); \ idem > WARN_SINGLE_COPY_ALIGNME...

On Fri, Nov 25, 2016 at 12:33:48PM +0100, Christian Borntraeger wrote: > On 11/25/2016 12:22 PM, Mark Rutland wrote: > > On Thu, Nov 24, 2016 at 10:36:58PM +0200, Michael S. Tsirkin wrote: > >> Though I really question the whole _ONCE APIs esp with > >> aggregate types - these seem to generate a memcpy and > >> an 8-byte read/writes sometimes, and I'm pretty

On Fri, Nov 25, 2016 at 12:33:48PM +0100, Christian Borntraeger wrote: > On 11/25/2016 12:22 PM, Mark Rutland wrote: > > On Thu, Nov 24, 2016 at 10:36:58PM +0200, Michael S. Tsirkin wrote: > >> Though I really question the whole _ONCE APIs esp with > >> aggregate types - these seem to generate a memcpy and > >> an 8-byte read/writes sometimes, and I'm pretty

..."wmb": : :"memory") > -#define read_barrier_depends() __asm__ __volatile__("mb": : :"memory") > +#define __smp_load_acquire(p) \ > +({ \ > + __unqual_scalar_typeof(*p) ___p1 = \ > + (*(volatile typeof(___p1) *)(p)); \ > + compiletime_assert_atomic_type(*p); \ > + ___p1; \ > +}) Sorry if I'm being thick, but doesn't this need a barrier after the volatile access to provide the acquire semantic? IIUC prior to this commit alpha would have used the asm-generic __smp_load_acquire, i.e. | #ifndef __smp_load_acquire | #define...

..."wmb": : :"memory") > -#define read_barrier_depends() __asm__ __volatile__("mb": : :"memory") > +#define __smp_load_acquire(p) \ > +({ \ > + __unqual_scalar_typeof(*p) ___p1 = \ > + (*(volatile typeof(___p1) *)(p)); \ > + compiletime_assert_atomic_type(*p); \ > + ___p1; \ > +}) Sorry if I'm being thick, but doesn't this need a barrier after the volatile access to provide the acquire semantic? IIUC prior to this commit alpha would have used the asm-generic __smp_load_acquire, i.e. | #ifndef __smp_load_acquire | #define...

...+#define __smp_store_mb(var, value) do { (void)xchg(&var, value); } while (0) #if defined(CONFIG_X86_PPRO_FENCE) @@ -50,31 +43,31 @@ * model and we should fall back to full barriers. */ -#define smp_store_release(p, v) \ +#define __smp_store_release(p, v) \ do { \ compiletime_assert_atomic_type(*p); \ - smp_mb(); \ + __smp_mb(); \ WRITE_ONCE(*p, v); \ } while (0) -#define smp_load_acquire(p) \ +#define __smp_load_acquire(p) \ ({ \ typeof(*p) ___p1 = READ_ONCE(*p); \ compiletime_assert_atomic_type(*p); \ - smp_mb(); \ + __smp_mb(...

On Fri, Nov 25, 2016 at 01:44:04PM +0100, Peter Zijlstra wrote: > On Fri, Nov 25, 2016 at 01:40:44PM +0100, Peter Zijlstra wrote: > > #define SINGLE_LOAD(x) \ > > {( \ > > compiletime_assert_atomic_type(typeof(x)); \ > > Should be: > > compiletime_assert_atomic_type(x); > > > WARN_SINGLE_COPY_ALIGNMENT(&(x)); \ Do we need to worry about the side effect on x? Maybe #define SINGLE_LOAD(x) \ ({ \ typeof(x) *_____ptr; \ \ compiletime_assert_ato...

...2016 at 01:44:04PM +0100, Peter Zijlstra wrote: >> On Fri, Nov 25, 2016 at 01:40:44PM +0100, Peter Zijlstra wrote: >> > #define SINGLE_LOAD(x) \ >> > {( \ >> > compiletime_assert_atomic_type(typeof(x)); \ >> >> Should be: >> >> compiletime_assert_atomic_type(x); >> >> > WARN_SINGLE_COPY_ALIGNMENT(&(x)); \ > > Do we need to worry about the side effect on x? Maybe > > #define SINGLE_LOAD(...

...2016 at 01:44:04PM +0100, Peter Zijlstra wrote: >> On Fri, Nov 25, 2016 at 01:40:44PM +0100, Peter Zijlstra wrote: >> > #define SINGLE_LOAD(x) \ >> > {( \ >> > compiletime_assert_atomic_type(typeof(x)); \ >> >> Should be: >> >> compiletime_assert_atomic_type(x); >> >> > WARN_SINGLE_COPY_ALIGNMENT(&(x)); \ > > Do we need to worry about the side effect on x? Maybe > > #define SINGLE_LOAD(...

...tructions from being > @@ -67,18 +59,18 @@ > #define data_barrier(x) \ > asm volatile("twi 0,%0,0; isync" : : "r" (x) : "memory"); > > -#define smp_store_release(p, v) \ > +#define __smp_store_release(p, v) \ > do { \ > compiletime_assert_atomic_type(*p); \ > - smp_lwsync(); \ > + __smp_lwsync(); \ , therefore this will emit an lwsync no matter SMP or UP. Another thing is that smp_lwsync() may have a third user(other than smp_load_acquire() and smp_store_release()): http://article.gmane.org/gmane.linux.ports.ppc.embedde...

...tructions from being > @@ -67,18 +59,18 @@ > #define data_barrier(x) \ > asm volatile("twi 0,%0,0; isync" : : "r" (x) : "memory"); > > -#define smp_store_release(p, v) \ > +#define __smp_store_release(p, v) \ > do { \ > compiletime_assert_atomic_type(*p); \ > - smp_lwsync(); \ > + __smp_lwsync(); \ , therefore this will emit an lwsync no matter SMP or UP. Another thing is that smp_lwsync() may have a third user(other than smp_load_acquire() and smp_store_release()): http://article.gmane.org/gmane.linux.ports.ppc.embedde...

...\ > > > +({ \ > > > + __unqual_scalar_typeof(*p) ___p1 = \ > > > + (*(volatile typeof(___p1) *)(p)); \ > > > + compiletime_assert_atomic_type(*p); \ > > > + ___p1; \ > > > +}) > > > > Sorry if I'm being thick, but doesn't this need a barrier after the > > volatile access to provide the acquire semantic? >...

...\ > > > +({ \ > > > + __unqual_scalar_typeof(*p) ___p1 = \ > > > + (*(volatile typeof(___p1) *)(p)); \ > > > + compiletime_assert_atomic_type(*p); \ > > > + ___p1; \ > > > +}) > > > > Sorry if I'm being thick, but doesn't this need a barrier after the > > volatile access to provide the acquire semantic? >...

Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the

Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't

This is really trying to cleanup some virt code, as suggested by Peter, who said > You could of course go fix that instead of mutilating things into > sort-of functional state. This work is needed for virtio, so it's probably easiest to merge it through my tree - is this fine by everyone? Arnd, if you agree, could you ack this please? Note to arch maintainers: please don't

...data_barrier(x) \ > > > asm volatile("twi 0,%0,0; isync" : : "r" (x) : "memory"); > > > > > > -#define smp_store_release(p, v) \ > > > +#define __smp_store_release(p, v) \ > > > do { \ > > > compiletime_assert_atomic_type(*p); \ > > > - smp_lwsync(); \ > > > + __smp_lwsync(); \ > > > > , therefore this will emit an lwsync no matter SMP or UP. > > Absolutely. But smp_store_release (without __) will not. > > Please note I did test this: for ppc code before a...

...data_barrier(x) \ > > > asm volatile("twi 0,%0,0; isync" : : "r" (x) : "memory"); > > > > > > -#define smp_store_release(p, v) \ > > > +#define __smp_store_release(p, v) \ > > > do { \ > > > compiletime_assert_atomic_type(*p); \ > > > - smp_lwsync(); \ > > > + __smp_lwsync(); \ > > > > , therefore this will emit an lwsync no matter SMP or UP. > > Absolutely. But smp_store_release (without __) will not. > > Please note I did test this: for ppc code before a...