Merge branch 'locking-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel...

Pull locking changes from Ingo Molnar:
 "The main changes in this cycle were:

   - More gradual enhancements to atomic ops: new atomic*_read_ctrl()
     ops, synchronize atomic_{read,set}() ordering requirements between
     architectures, add atomic_long_t bitops.  (Peter Zijlstra)

   - Add _{relaxed|acquire|release}() variants for inc/dec atomics and
     use them in various locking primitives: mutex, rtmutex, mcs, rwsem.
     This enables weakly ordered architectures (such as arm64) to make
     use of more locking related optimizations.  (Davidlohr Bueso)

   - Implement atomic[64]_{inc,dec}_relaxed() on ARM.  (Will Deacon)

   - Futex kernel data cache footprint micro-optimization.  (Rasmus
     Villemoes)

   - pvqspinlock runtime overhead micro-optimization.  (Waiman Long)

   - misc smaller fixlets"

* 'locking-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  ARM, locking/atomics: Implement _relaxed variants of atomic[64]_{inc,dec}
  locking/rwsem: Use acquire/release semantics
  locking/mcs: Use acquire/release semantics
  locking/rtmutex: Use acquire/release semantics
  locking/mutex: Use acquire/release semantics
  locking/asm-generic: Add _{relaxed|acquire|release}() variants for inc/dec atomics
  atomic: Implement atomic_read_ctrl()
  atomic, arch: Audit atomic_{read,set}()
  atomic: Add atomic_long_t bitops
  futex: Force hot variables into a single cache line
  locking/pvqspinlock: Kick the PV CPU unconditionally when _Q_SLOW_VAL
  locking/osq: Relax atomic semantics
  locking/qrwlock: Rename ->lock to ->wait_lock
  locking/Documentation/lockstat: Fix typo - lokcing -> locking
  locking/atomics, cmpxchg: Privatize the inclusion of asm/cmpxchg.h

diff --combined Documentation/memory-barriers.txt
index 8e7cf9ad3db131c3f82621043fd7184ed025d088,41ffd7e9cdcfddf85bf26907fdcf6e41285391be..b5fe7657456e687628361adda87d3766dd5327ef
--- 1/Documentation/memory-barriers.txt
--- 2/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@@ -637,7 -637,8 +637,8 @@@ as follows
        b = p;  /* BUG: Compiler and CPU can both reorder!!! */
  
  Finally, the READ_ONCE_CTRL() includes an smp_read_barrier_depends()
- that DEC Alpha needs in order to respect control depedencies.
+ that DEC Alpha needs in order to respect control depedencies. Alternatively
+ use one of atomic{,64}_read_ctrl().
  
  So don't leave out the READ_ONCE_CTRL().
  
@@@ -796,9 -797,9 +797,9 @@@ site: https://www.cl.cam.ac.uk/~pes20/p
  
  In summary:
  
-   (*) Control dependencies must be headed by READ_ONCE_CTRL().
-       Or, as a much less preferable alternative, interpose
-       smp_read_barrier_depends() between a READ_ONCE() and the
+   (*) Control dependencies must be headed by READ_ONCE_CTRL(),
+       atomic{,64}_read_ctrl(). Or, as a much less preferable alternative,
+       interpose smp_read_barrier_depends() between a READ_ONCE() and the
        control-dependent write.
  
    (*) Control dependencies can order prior loads against later stores.
@@@ -820,10 -821,10 +821,10 @@@
        and WRITE_ONCE() can help to preserve the needed conditional.
  
    (*) Control dependencies require that the compiler avoid reordering the
-       dependency into nonexistence.  Careful use of READ_ONCE_CTRL()
-       or smp_read_barrier_depends() can help to preserve your control
-       dependency.  Please see the Compiler Barrier section for more
-       information.
+       dependency into nonexistence.  Careful use of READ_ONCE_CTRL(),
+       atomic{,64}_read_ctrl() or smp_read_barrier_depends() can help to
+       preserve your control dependency.  Please see the Compiler Barrier
+       section for more information.
  
    (*) Control dependencies pair normally with other types of barriers.
  
@@@ -1710,17 -1711,6 +1711,17 @@@ There are some more advanced barrier fu
       operations" subsection for information on where to use these.
  
  
 + (*) lockless_dereference();
 +     This can be thought of as a pointer-fetch wrapper around the
 +     smp_read_barrier_depends() data-dependency barrier.
 +
 +     This is also similar to rcu_dereference(), but in cases where
 +     object lifetime is handled by some mechanism other than RCU, for
 +     example, when the objects removed only when the system goes down.
 +     In addition, lockless_dereference() is used in some data structures
 +     that can be used both with and without RCU.
 +
 +
   (*) dma_wmb();
   (*) dma_rmb();
  
@@@ -1800,6 -1790,7 +1801,6 @@@ The Linux kernel has a number of lockin
   (*) mutexes
   (*) semaphores
   (*) R/W semaphores
 - (*) RCU
  
  In all cases there are variants on "ACQUIRE" operations and "RELEASE" operations
  for each construct.  These operations all imply certain barriers: