search for: smp_mb__before_atomic

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 instead. > > This is in preparation to refactoring this code area. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > Acked-by: Arn...

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 instead. > > This is in preparation to refactoring this code area. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > Acked-by: Arn...

...t; + kvmi_end_introspection(ikvm); > + > + return 0; > +} > + Rename this to kvmi_recv_thread instead, please. > + > + /* > + * Make sure all the KVM/KVMI structures are linked and no pointer > + * is read as NULL after the reference count has been set. > + */ > + smp_mb__before_atomic(); This is an smp_wmb(), not an smp_mb__before_atomic(). Add a comment that it pairs with the refcount_inc_not_zero in kvmi_get. > + refcount_set(&kvm->kvmi_ref, 1); > + > @@ -57,8 +183,27 @@ void kvmi_destroy_vm(struct kvm *kvm) > if (!ikvm) > return; > > +...

...hwidefsky wrote: > On Mon, 4 Jan 2016 14:20:42 +0100 > Peter Zijlstra <peterz at infradead.org> wrote: > > > 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 instead. > > > > > > This is in preparation to refactoring this code area. > > > > > > Signed-off-by: Mic...

...hwidefsky wrote: > On Mon, 4 Jan 2016 14:20:42 +0100 > Peter Zijlstra <peterz at infradead.org> wrote: > > > 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 instead. > > > > > > This is in preparation to refactoring this code area. > > > > > > Signed-off-by: Mic...

...ge work->node->next. That is why we use _safe, but we need to ensure that llist_for_each_safe() completes LOAD(work->node->next) before VHOST_WORK_QUEUED is cleared. So it seems that smp_wmb() can't help and should be removed, instead we need llist_for_each_entry_safe(...) { smp_mb__before_atomic(); clear_bit(VHOST_WORK_QUEUED, &work->flags); Also, if the work->fn pointer is not stable, we should read it before smp_mb__before_atomic() as well. No? __set_current_state(TASK_RUNNING); Why do we set TASK_RUNNING inside the loop? Does this mean that work->fn() can return...

Changes since v2: - extended checkpatch tests for barriers, and added patches teaching it to warn about incorrect usage of barriers (__smp_xxx barriers are for use by asm-generic code only), should help prevent misuse by arch code to address comments by Russell King - patched more instances of xen to use virt_ barriers as suggested by Stefano Stabellini - implemented a 2 byte xchg on sh

Changes since v2: - extended checkpatch tests for barriers, and added patches teaching it to warn about incorrect usage of barriers (__smp_xxx barriers are for use by asm-generic code only), should help prevent misuse by arch code to address comments by Russell King - patched more instances of xen to use virt_ barriers as suggested by Stefano Stabellini - implemented a 2 byte xchg on sh

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

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

...structions which imply a memory barrier or QDIO which uses atomics. > But I also see a lot of weirdness on this architecture. Mostly historical, s390 actually is one of the easiest architectures in regard to memory barriers. > I found these calls: > > arch/s390/include/asm/bitops.h: smp_mb__before_atomic(); > arch/s390/include/asm/bitops.h: smp_mb(); > > Not used in arch specific code so this is likely OK. This has been introduced with git commit 5402ea6af11dc5a9, the smp_mb and smp_mb__before_atomic are used in clear_bit_unlock and __clear_bit_unlock which are 1:1 copies from the code i...

...structions which imply a memory barrier or QDIO which uses atomics. > But I also see a lot of weirdness on this architecture. Mostly historical, s390 actually is one of the easiest architectures in regard to memory barriers. > I found these calls: > > arch/s390/include/asm/bitops.h: smp_mb__before_atomic(); > arch/s390/include/asm/bitops.h: smp_mb(); > > Not used in arch specific code so this is likely OK. This has been introduced with git commit 5402ea6af11dc5a9, the smp_mb and smp_mb__before_atomic are used in clear_bit_unlock and __clear_bit_unlock which are 1:1 copies from the code i...

...__SUBARCH_HAS_LWSYNC > # define SMPWMB LWSYNC > diff --git a/arch/s390/include/asm/barrier.h b/arch/s390/include/asm/barrier.h > index d68e11e..7ffd0b1 100644 > --- a/arch/s390/include/asm/barrier.h > +++ b/arch/s390/include/asm/barrier.h > @@ -36,7 +36,7 @@ > #define smp_mb__before_atomic() smp_mb() > #define smp_mb__after_atomic() smp_mb() > > -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); mb(); } while (0) > +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); } while (0) > > #define smp_store_release(p, v) \ >...

...__SUBARCH_HAS_LWSYNC > # define SMPWMB LWSYNC > diff --git a/arch/s390/include/asm/barrier.h b/arch/s390/include/asm/barrier.h > index d68e11e..7ffd0b1 100644 > --- a/arch/s390/include/asm/barrier.h > +++ b/arch/s390/include/asm/barrier.h > @@ -36,7 +36,7 @@ > #define smp_mb__before_atomic() smp_mb() > #define smp_mb__after_atomic() smp_mb() > > -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); mb(); } while (0) > +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); } while (0) > > #define smp_store_release(p, v) \ >...

...> @@ -93,7 +93,7 @@ > #endif /* CONFIG_SMP */ > > #ifndef smp_store_mb > -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); mb(); } while (0) > +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); } while (0) > #endif > > #ifndef smp_mb__before_atomic > The same patch is already in the tip tree scheduled for 4.5 as d5a73cadf3fd ("lcoking/barriers, arch: Use smp barriers in smp_store_release()"). I think you can drop your version. arnd

...> @@ -93,7 +93,7 @@ > #endif /* CONFIG_SMP */ > > #ifndef smp_store_mb > -#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); mb(); } while (0) > +#define smp_store_mb(var, value) do { WRITE_ONCE(var, value); smp_mb(); } while (0) > #endif > > #ifndef smp_mb__before_atomic > The same patch is already in the tip tree scheduled for 4.5 as d5a73cadf3fd ("lcoking/barriers, arch: Use smp barriers in smp_store_release()"). I think you can drop your version. arnd

On arm smp_store_mb, read_barrier_depends, smp_read_barrier_depends, smp_store_release, smp_load_acquire, 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 instead. This is in preparation to refactoring this code area. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> Acked-by: Arnd Bergmann <arnd at arndb.de>...

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 instead. This is in preparation to refactoring this code area. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> Acked-by: Arnd Bergmann <arnd at arndb.de>...