search for: smp_store_mb

On Wednesday 30 December 2015 15:24:47 Michael S. Tsirkin wrote: > asm-generic variant of smp_store_mb() calls mb() which is stronger > than implied by both the name and the documentation. > > smp_store_mb is only used by core kernel code at the moment, so > we know no one mis-uses it for an MMIO barrier. > Make it call smp_mb consistently before some arch-specific > code uses it...

On Wednesday 30 December 2015 15:24:47 Michael S. Tsirkin wrote: > asm-generic variant of smp_store_mb() calls mb() which is stronger > than implied by both the name and the documentation. > > smp_store_mb is only used by core kernel code at the moment, so > we know no one mis-uses it for an MMIO barrier. > Make it call smp_mb consistently before some arch-specific > code uses it...

On Sun, Jan 10, 2016 at 04:16:32PM +0200, Michael S. Tsirkin wrote: > From: Davidlohr Bueso <dave at stgolabs.net> > > With commit b92b8b35a2e ("locking/arch: Rename set_mb() to smp_store_mb()") > it was made clear that the context of this call (and thus set_mb) > is strictly for CPU ordering, as opposed to IO. As such all archs > should use the smp variant of mb(), respecting the semantics and > saving a mandatory barrier on UP. > > Signed-off-by: Davidlohr Bue...

On Sun, Jan 10, 2016 at 04:16:32PM +0200, Michael S. Tsirkin wrote: > From: Davidlohr Bueso <dave at stgolabs.net> > > With commit b92b8b35a2e ("locking/arch: Rename set_mb() to smp_store_mb()") > it was made clear that the context of this call (and thus set_mb) > is strictly for CPU ordering, as opposed to IO. As such all archs > should use the smp variant of mb(), respecting the semantics and > saving a mandatory barrier on UP. > > Signed-off-by: Davidlohr Bue...

On Sun, Dec 20, 2015 at 05:07:19PM +0000, Andrew Cooper wrote: > > Very much +1 for fixing this. > > Those names would be fine, but they do add yet another set of options in > an already-complicated area. > > An alternative might be to have the regular smp_{w,r,}mb() not revert > back to nops if CONFIG_PARAVIRT, or perhaps if pvops have detected a > non-native

On Sun, Dec 20, 2015 at 05:07:19PM +0000, Andrew Cooper wrote: > > Very much +1 for fixing this. > > Those names would be fine, but they do add yet another set of options in > an already-complicated area. > > An alternative might be to have the regular smp_{w,r,}mb() not revert > back to nops if CONFIG_PARAVIRT, or perhaps if pvops have detected a > non-native

asm-generic variant of smp_store_mb() calls mb() which is stronger than implied by both the name and the documentation. smp_store_mb is only used by core kernel code at the moment, so we know no one mis-uses it for an MMIO barrier. Make it call smp_mb consistently before some arch-specific code uses it as such by mistake. Signed-of...

On Wed, Dec 30, 2015 at 02:44:21PM +0100, Arnd Bergmann wrote: > On Wednesday 30 December 2015 15:24:47 Michael S. Tsirkin wrote: > > asm-generic variant of smp_store_mb() calls mb() which is stronger > > than implied by both the name and the documentation. > > > > smp_store_mb is only used by core kernel code at the moment, so > > we know no one mis-uses it for an MMIO barrier. > > Make it call smp_mb consistently before some arch-sp...

We need a full barrier after writing out event index, using smp_store_mb there seems better than open-coding. As usual, we need a wrapper to account for strong barriers/non smp. It's tempting to use this in vhost as well, for that, we'll need a variant of smp_store_mb that works on __user pointers. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --...

We need a full barrier after writing out event index, using smp_store_mb there seems better than open-coding. As usual, we need a wrapper to account for strong barriers/non smp. It's tempting to use this in vhost as well, for that, we'll need a variant of smp_store_mb that works on __user pointers. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --...

...0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 12:32:53PM +0200, Michael S. Tsirkin wrote: > > +static inline void virtio_store_mb(bool weak_barriers, > > + __virtio16 *p, __virtio16 v) > > +{ > > +#ifdef CONFIG_SMP > > + if (weak_barriers) > > + smp_store_mb(*p, v); > > + else > > +#endif > > + { > > + WRITE_ONCE(*p, v); > > + mb(); > > + } > > +} > > This is a different barrier depending on SMP, that seems wrong. Of course it's wrong in the sense that it's suboptimal on UP. What we would real...

...0100, Peter Zijlstra wrote: > On Thu, Dec 17, 2015 at 12:32:53PM +0200, Michael S. Tsirkin wrote: > > +static inline void virtio_store_mb(bool weak_barriers, > > + __virtio16 *p, __virtio16 v) > > +{ > > +#ifdef CONFIG_SMP > > + if (weak_barriers) > > + smp_store_mb(*p, v); > > + else > > +#endif > > + { > > + WRITE_ONCE(*p, v); > > + mb(); > > + } > > +} > > This is a different barrier depending on SMP, that seems wrong. Of course it's wrong in the sense that it's suboptimal on UP. What we would real...

sh variant of smp_store_mb() calls xchg() on !SMP which is stronger than implied by both the name and the documentation. commit 90a3ccb0be538a914e6a5c51ae919762261563ad ("sh: define __smp_xxx, fix smp_store_mb for !SMP") was supposed to fix it but left the bug in place. Drop smp_store_mb, so that code in asm-gene...

sh variant of smp_store_mb() calls xchg() on !SMP which is stronger than implied by both the name and the documentation. commit 90a3ccb0be538a914e6a5c51ae919762261563ad ("sh: define __smp_xxx, fix smp_store_mb for !SMP") was supposed to fix it but left the bug in place. Drop smp_store_mb, so that code in asm-gene...

From: Davidlohr Bueso <dave at stgolabs.net> With commit b92b8b35a2e ("locking/arch: Rename set_mb() to smp_store_mb()") it was made clear that the context of this call (and thus set_mb) is strictly for CPU ordering, as opposed to IO. As such all archs should use the smp variant of mb(), respecting the semantics and saving a mandatory barrier on UP. Signed-off-by: Davidlohr Bueso <dbueso at suse.de> S...

...t; On Thu, Dec 17, 2015 at 12:32:53PM +0200, Michael S. Tsirkin wrote: > > > +static inline void virtio_store_mb(bool weak_barriers, > > > + __virtio16 *p, __virtio16 v) > > > +{ > > > +#ifdef CONFIG_SMP > > > + if (weak_barriers) > > > + smp_store_mb(*p, v); > > > + else > > > +#endif > > > + { > > > + WRITE_ONCE(*p, v); > > > + mb(); > > > + } > > > +} > > > > This is a different barrier depending on SMP, that seems wrong. > > Of course it's wrong in the s...

On Thu, Dec 17, 2015 at 12:32:53PM +0200, Michael S. Tsirkin wrote: > +static inline void virtio_store_mb(bool weak_barriers, > + __virtio16 *p, __virtio16 v) > +{ > +#ifdef CONFIG_SMP > + if (weak_barriers) > + smp_store_mb(*p, v); > + else > +#endif > + { > + WRITE_ONCE(*p, v); > + mb(); > + } > +} This is a different barrier depending on SMP, that seems wrong. smp_mb(), as (should be) used by smp_store_mb() does not provide a barrier against IO. mb() otoh does. Since this is virtIO I would...

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. Check size and fall back to a slower, but safe, WRITE_ONCE+smp_mb. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- arch/sh/include/asm/barrier.h | 10 +++++++++...

...ence on at least recent machines, see: lkml.kernel.org/r/CA+55aFynbkeuUGs9s-q+fLY6MeRBA6MjEyWWbbe7A5AaqsAknw at mail.gmail.com > +static inline void virtio_store_mb(bool weak_barriers, > + __virtio16 *p, __virtio16 v) > +{ > +#ifdef CONFIG_SMP > + if (weak_barriers) > + smp_store_mb(*p, v); > + else > +#endif > + { > + WRITE_ONCE(*p, v); > + mb(); > + } > +} Note that virtio_mb() is weirdly inconsistent with virtio_[rw]mb() in that they use dma_* ops for weak_barriers, while virtio_mb() uses smp_mb(). As previously stated, smp_mb() does not cover the s...

...vide this ability: if CONFIG_SMP is not defined is optimizes most barriers out to a compiler barrier. Consider for example x86: what we want is xchg (NOT mfence - there's no real IO going on here - just switching out of the VM - more like a function call really) but if built without CONFIG_SMP smp_store_mb does not include this. Virt in general is probably the only use-case, because this really is an artifact of interfacing with an SMP host while running an UP kernel, but since we have (at least) two users, it seems to make sense to put these APIs in a central place. In fact, smp_ barriers are stub...