Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost

Pull virtio barrier rework+fixes from Michael Tsirkin:
 "This adds a new kind of barrier, and reworks virtio and xen to use it.

  Plus some fixes here and there"

* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: (44 commits)
  checkpatch: add virt barriers
  checkpatch: check for __smp outside barrier.h
  checkpatch.pl: add missing memory barriers
  virtio: make find_vqs() checkpatch.pl-friendly
  virtio_balloon: fix race between migration and ballooning
  virtio_balloon: fix race by fill and leak
  s390: more efficient smp barriers
  s390: use generic memory barriers
  xen/events: use virt_xxx barriers
  xen/io: use virt_xxx barriers
  xenbus: use virt_xxx barriers
  virtio_ring: use virt_store_mb
  sh: move xchg_cmpxchg to a header by itself
  sh: support 1 and 2 byte xchg
  virtio_ring: update weak barriers to use virt_xxx
  Revert "virtio_ring: Update weak barriers to use dma_wmb/rmb"
  asm-generic: implement virt_xxx memory barriers
  x86: define __smp_xxx
  xtensa: define __smp_xxx
  tile: define __smp_xxx
  ...

diff --combined Documentation/memory-barriers.txt
index a61be39c7b516a1e3b081afd1fea02a3f1068187,8f4a93aae19fb155a6676d0ede6261649f01e493..904ee42d078e51d8b43fe6548611219c2c0444c0
--- 1/Documentation/memory-barriers.txt
--- 2/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@@ -194,7 -194,7 +194,7 @@@ There are some minimal guarantees that 
   (*) On any given CPU, dependent memory accesses will be issued in order, with
       respect to itself.  This means that for:
  
 -      WRITE_ONCE(Q, P); smp_read_barrier_depends(); D = READ_ONCE(*Q);
 +      Q = READ_ONCE(P); smp_read_barrier_depends(); D = READ_ONCE(*Q);
  
       the CPU will issue the following memory operations:
  
@@@ -202,9 -202,9 +202,9 @@@
  
       and always in that order.  On most systems, smp_read_barrier_depends()
       does nothing, but it is required for DEC Alpha.  The READ_ONCE()
 -     and WRITE_ONCE() are required to prevent compiler mischief.  Please
 -     note that you should normally use something like rcu_dereference()
 -     instead of open-coding smp_read_barrier_depends().
 +     is required to prevent compiler mischief.  Please note that you
 +     should normally use something like rcu_dereference() instead of
 +     open-coding smp_read_barrier_depends().
  
   (*) Overlapping loads and stores within a particular CPU will appear to be
       ordered within that CPU.  This means that for:
@@@ -1655,17 -1655,18 +1655,18 @@@ macro is a good place to start looking
  SMP memory barriers are reduced to compiler barriers on uniprocessor compiled
  systems because it is assumed that a CPU will appear to be self-consistent,
  and will order overlapping accesses correctly with respect to itself.
+ However, see the subsection on "Virtual Machine Guests" below.
  
  [!] Note that SMP memory barriers _must_ be used to control the ordering of
  references to shared memory on SMP systems, though the use of locking instead
  is sufficient.
  
  Mandatory barriers should not be used to control SMP effects, since mandatory
- barriers unnecessarily impose overhead on UP systems. They may, however, be
- used to control MMIO effects on accesses through relaxed memory I/O windows.
- These are required even on non-SMP systems as they affect the order in which
- memory operations appear to a device by prohibiting both the compiler and the
- CPU from reordering them.
+ barriers impose unnecessary overhead on both SMP and UP systems. They may,
+ however, be used to control MMIO effects on accesses through relaxed memory I/O
+ windows.  These barriers are required even on non-SMP systems as they affect
+ the order in which memory operations appear to a device by prohibiting both the
+ compiler and the CPU from reordering them.
  
  
  There are some more advanced barrier functions:
@@@ -1673,8 -1674,8 +1674,8 @@@
   (*) smp_store_mb(var, value)
  
       This assigns the value to the variable and then inserts a full memory
 -     barrier after it, depending on the function.  It isn't guaranteed to
 -     insert anything more than a compiler barrier in a UP compilation.
 +     barrier after it.  It isn't guaranteed to insert anything more than a
 +     compiler barrier in a UP compilation.
  
  
   (*) smp_mb__before_atomic();
@@@ -2948,6 -2949,23 +2949,23 @@@ The Alpha defines the Linux kernel's me
  
  See the subsection on "Cache Coherency" above.
  
+ VIRTUAL MACHINE GUESTS
+ -------------------
+ 
+ Guests running within virtual machines might be affected by SMP effects even if
+ the guest itself is compiled without SMP support.  This is an artifact of
+ interfacing with an SMP host while running an UP kernel.  Using mandatory
+ barriers for this use-case would be possible but is often suboptimal.
+ 
+ To handle this case optimally, low-level virt_mb() etc macros are available.
+ These have the same effect as smp_mb() etc when SMP is enabled, but generate
+ identical code for SMP and non-SMP systems. For example, virtual machine guests
+ should use virt_mb() rather than smp_mb() when synchronizing against a
+ (possibly SMP) host.
+ 
+ These are equivalent to smp_mb() etc counterparts in all other respects,
+ in particular, they do not control MMIO effects: to control
+ MMIO effects, use mandatory barriers.
  
  ============
  EXAMPLE USES