1. 27 Apr, 2018 1 commit
  2. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      
      
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      
      How this work was done:
      
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      
      Further patches will be generated in subsequent months to fix up cases
      where non-standard license headers were used, and references to license
      had to be inferred by heuristics based on keywords.
      
      The analysis to determine which SPDX License Identifier to be applied to
      a file was done in a spreadsheet of side by side results from of the
      output of two independent scanners (ScanCode & Windriver) producing SPDX
      tag:value files created by Philippe Ombredanne.  Philippe prepared the
      base worksheet, and did an initial spot review of a few 1000 files.
      
      The 4.13 kernel was the starting point of the analysis with 60,537 files
      assessed.  Kate Stewart did a file by file comparison of the scanner
      results in the spreadsheet to determine which SPDX license identifier(s)
      to be applied to the file. She confirmed any determination that was not
      immediately clear with lawyers working with the Linux Foundation.
      
      Criteria used to select files for SPDX license identifier tagging was:
       - Files considered eligible had to be source code files.
       - Make and config files were included as candidates if they contained >5
         lines of source
       - File already had some variant of a license header in it (even if <5
         lines).
      
      All documentation files were explicitly excluded.
      
      The following heuristics were used to determine which SPDX license
      identifiers to apply.
      
       - when both scanners couldn't find any license traces, file was
         considered to have no license information in it, and the top level
         COPYING file license applied.
      
         For non */uapi/* files that summary was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0                                              11139
      
         and resulted in the first patch in this series.
      
         If that file was a */uapi/* path one, it was "GPL-2.0 WITH
         Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|-------
         GPL-2.0 WITH Linux-syscall-note                        930
      
         and resulted in the second patch in this series.
      
       - if a file had some form of licensing information in it, and was one
         of the */uapi/* ones, it was denoted with the Linux-syscall-note if
         any GPL family license was found in the file or had no licensing in
         it (per prior point).  Results summary:
      
         SPDX license identifier                            # files
         ---------------------------------------------------|------
         GPL-2.0 WITH Linux-syscall-note                       270
         GPL-2.0+ WITH Linux-syscall-note                      169
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
         ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
         LGPL-2.1+ WITH Linux-syscall-note                      15
         GPL-1.0+ WITH Linux-syscall-note                       14
         ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
         LGPL-2.0+ WITH Linux-syscall-note                       4
         LGPL-2.1 WITH Linux-syscall-note                        3
         ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
         ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1
      
         and that resulted in the third patch in this series.
      
       - when the two scanners agreed on the detected license(s), that became
         the concluded license(s).
      
       - when there was disagreement between the two scanners (one detected a
         license but the other didn't, or they both detected different
         licenses) a manual inspection of the file occurred.
      
       - In most cases a manual inspection of the information in the file
         resulted in a clear resolution of the license that should apply (and
         which scanner probably needed to revisit its heuristics).
      
       - When it was not immediately clear, the license identifier was
         confirmed with lawyers working with the Linux Foundation.
      
       - If there was any question as to the appropriate license identifier,
         the file was flagged for further research and to be revisited later
         in time.
      
      In total, over 70 hours of logged manual review was done on the
      spreadsheet to determine the SPDX license identifiers to apply to the
      source files by Kate, Philippe, Thomas and, in some cases, confirmation
      by lawyers working with the Linux Foundation.
      
      Kate also obtained a third independent scan of the 4.13 code base from
      FOSSology, and compared selected files where the other two scanners
      disagreed against that SPDX file, to see if there was new insights.  The
      Windriver scanner is based on an older version of FOSSology in part, so
      they are related.
      
      Thomas did random spot checks in about 500 files from the spreadsheets
      for the uapi headers and agreed with SPDX license identifier in the
      files he inspected. For the non-uapi files Thomas did random spot checks
      in about 15000 files.
      
      In initial set of patches against 4.14-rc6, 3 files were found to have
      copy/paste license identifier errors, and have been fixed to reflect the
      correct identifier.
      
      Additionally Philippe spent 10 hours this week doing a detailed manual
      inspection and review of the 12,461 patched files from the initial patch
      version early this week with:
       - a full scancode scan run, collecting the matched texts, detected
         license ids and scores
       - reviewing anything where there was a license detected (about 500+
         files) to ensure that the applied SPDX license was correct
       - reviewing anything where there was no detection but the patch license
         was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
         SPDX license was correct
      
      This produced a worksheet with 20 files needing minor correction.  This
      worksheet was then exported into 3 different .csv files for the
      different types of files to be modified.
      
      These .csv files were then reviewed by Greg.  Thomas wrote a script to
      parse the csv files and add the proper SPDX tag to the file, in the
      format that the file expected.  This script was further refined by Greg
      based on the output to detect more types of files automatically and to
      distinguish between header and source .c files (which need different
      comment types.)  Finally Greg ran the script using the .csv files to
      generate the patches.
      Reviewed-by: default avatarKate Stewart <kstewart@linuxfoundation.org>
      Reviewed-by: default avatarPhilippe Ombredanne <pombredanne@nexb.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318
  3. 25 Oct, 2017 1 commit
  4. 10 Aug, 2017 1 commit
    • Peter Zijlstra's avatar
      locking: Introduce smp_mb__after_spinlock() · d89e588c
      Peter Zijlstra authored
      
      
      Since its inception, our understanding of ACQUIRE, esp. as applied to
      spinlocks, has changed somewhat. Also, I wonder if, with a simple
      change, we cannot make it provide more.
      
      The problem with the comment is that the STORE done by spin_lock isn't
      itself ordered by the ACQUIRE, and therefore a later LOAD can pass over
      it and cross with any prior STORE, rendering the default WMB
      insufficient (pointed out by Alan).
      
      Now, this is only really a problem on PowerPC and ARM64, both of
      which already defined smp_mb__before_spinlock() as a smp_mb().
      
      At the same time, we can get a much stronger construct if we place
      that same barrier _inside_ the spin_lock(). In that case we upgrade
      the RCpc spinlock to an RCsc.  That would make all schedule() calls
      fully transitive against one another.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Nicholas Piggin <npiggin@gmail.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      d89e588c
  5. 30 Mar, 2017 1 commit
    • Peter Zijlstra's avatar
      locking/atomic: Fix atomic_try_cmpxchg() semantics · 44fe8445
      Peter Zijlstra authored
      
      
      Dmitry noted that the new atomic_try_cmpxchg() primitive is broken when
      the old pointer doesn't point to the local stack.
      
      He writes:
      
        "Consider a classical lock-free stack push:
      
          node->next = atomic_read(&head);
          do {
          } while (!atomic_try_cmpxchg(&head, &node->next, node));
      
        This code is broken with the current implementation, the problem is
        with unconditional update of *__po.
      
        In case of success it writes the same value back into *__po, but in
        case of cmpxchg success we might have lose ownership of some memory
        locations and potentially over what __po has pointed to. The same
        holds for the re-read of *__po. "
      
      He also points out that this makes it surprisingly different from the
      similar C/C++ atomic operation.
      
      After investigating the code-gen differences caused by this patch; and
      a number of alternatives (Linus dislikes this interface lots), we
      arrived at these results (size x86_64-defconfig/vmlinux):
      
        GCC-6.3.0:
      
        10735757        cmpxchg
        10726413        try_cmpxchg
        10730509        try_cmpxchg + patch
        10730445        try_cmpxchg-linus
      
        GCC-7 (20170327):
      
        10709514        cmpxchg
        10704266        try_cmpxchg
        10704266        try_cmpxchg + patch
        10704394        try_cmpxchg-linus
      
      From this we see that the patch has the advantage of better code-gen
      on GCC-7 and keeps the interface roughly consistent with the C
      language variant.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Fixes: a9ebf306
      
       ("locking/atomic: Introduce atomic_try_cmpxchg()")
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      44fe8445
  6. 23 Mar, 2017 1 commit
    • Peter Zijlstra's avatar
      locking/atomic: Introduce atomic_try_cmpxchg() · a9ebf306
      Peter Zijlstra authored
      
      
      Add a new cmpxchg interface:
      
        bool try_cmpxchg(u{8,16,32,64} *ptr, u{8,16,32,64} *val, u{8,16,32,64} new);
      
      Where the boolean returns the result of the compare; and thus if the
      exchange happened; and in case of failure, the new value of *ptr is
      returned in *val.
      
      This allows simplification/improvement of loops like:
      
      	for (;;) {
      		new = val $op $imm;
      		old = cmpxchg(ptr, val, new);
      		if (old == val)
      			break;
      		val = old;
      	}
      
      into:
      
      	do {
      	} while (!try_cmpxchg(ptr, &val, val $op $imm));
      
      while also generating better code (GCC6 and onwards).
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      a9ebf306
  7. 07 Jul, 2016 1 commit
    • Davidlohr Bueso's avatar
      locking/atomic: Introduce inc/dec variants for the atomic_fetch_$op() API · f0662863
      Davidlohr Bueso authored
      
      
      With the inclusion of atomic FETCH-OP variants, many places in the
      kernel can make use of atomic_fetch_$op() to avoid the callers that
      need to compute the value/state _before_ the operation.
      
      Peter Zijlstra laid out the machinery but we are still missing the
      simpler dec,inc() calls (which future patches will make use of).
      
      This patch only deals with the generic code, as at least right now
      no arch actually implement them -- which is similar to what the
      OP-RETURN primitives currently do.
      Signed-off-by: default avatarDavidlohr Bueso <dbueso@suse.de>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: James.Bottomley@HansenPartnership.com
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: awalls@md.metrocast.net
      Cc: bp@alien8.de
      Cc: cw00.choi@samsung.com
      Cc: davem@davemloft.net
      Cc: dledford@redhat.com
      Cc: dougthompson@xmission.com
      Cc: gregkh@linuxfoundation.org
      Cc: hans.verkuil@cisco.com
      Cc: heiko.carstens@de.ibm.com
      Cc: jikos@kernel.org
      Cc: kys@microsoft.com
      Cc: mchehab@osg.samsung.com
      Cc: pfg@sgi.com
      Cc: schwidefsky@de.ibm.com
      Cc: sean.hefty@intel.com
      Cc: sumit.semwal@linaro.org
      Link: http://lkml.kernel.org/r/20160628215651.GA20048@linux-80c1.suse
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      f0662863
  8. 16 Jun, 2016 4 commits
    • Peter Zijlstra's avatar
      locking/atomic: Remove the deprecated atomic_{set,clear}_mask() functions · e37837fb
      Peter Zijlstra authored
      
      
      These functions have been deprecated for a while and there is only the
      one user left, convert and kill.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      e37837fb
    • Peter Zijlstra's avatar
      locking/atomic: Remove linux/atomic.h:atomic_fetch_or() · b53d6bed
      Peter Zijlstra authored
      
      
      Since all architectures have this implemented now natively, remove this
      dead code.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      b53d6bed
    • Peter Zijlstra's avatar
      locking/atomic: Implement... · 28aa2bda
      Peter Zijlstra authored
      
      locking/atomic: Implement atomic{,64,_long}_fetch_{add,sub,and,andnot,or,xor}{,_relaxed,_acquire,_release}()
      
      Now that all the architectures have implemented support for these new
      atomic primitives add on the generic infrastructure to expose and use
      it.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Boqun Feng <boqun.feng@gmail.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      28aa2bda
    • Peter Zijlstra's avatar
      locking/atomic: Fix atomic64_relaxed() bits · e1213332
      Peter Zijlstra authored
      
      
      We should only expand the atomic64 relaxed bits once we've included
      all relevant headers. So move it down until after we potentially
      include asm-generic/atomic64.h.
      
      In practise this will not have made a difference so far, since the
      generic bits will not define _relaxed versions.
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      e1213332
  9. 05 May, 2016 1 commit
  10. 29 Mar, 2016 2 commits
  11. 17 Feb, 2016 1 commit
  12. 13 Feb, 2016 1 commit
    • Frederic Weisbecker's avatar
      atomic: Export fetch_or() · 5fd7a09c
      Frederic Weisbecker authored
      
      
      Export fetch_or() that's implemented and used internally by the
      scheduler. We are going to use it for NO_HZ so make it generally
      available.
      Reviewed-by: default avatarChris Metcalf <cmetcalf@ezchip.com>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Chris Metcalf <cmetcalf@ezchip.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Luiz Capitulino <lcapitulino@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      5fd7a09c
  13. 04 Nov, 2015 1 commit
    • Linus Torvalds's avatar
      atomic: remove all traces of READ_ONCE_CTRL() and atomic*_read_ctrl() · 105ff3cb
      Linus Torvalds authored
      
      
      This seems to be a mis-reading of how alpha memory ordering works, and
      is not backed up by the alpha architecture manual.  The helper functions
      don't do anything special on any other architectures, and the arguments
      that support them being safe on other architectures also argue that they
      are safe on alpha.
      
      Basically, the "control dependency" is between a previous read and a
      subsequent write that is dependent on the value read.  Even if the
      subsequent write is actually done speculatively, there is no way that
      such a speculative write could be made visible to other cpu's until it
      has been committed, which requires validating the speculation.
      
      Note that most weakely ordered architectures (very much including alpha)
      do not guarantee any ordering relationship between two loads that depend
      on each other on a control dependency:
      
          read A
          if (val == 1)
              read B
      
      because the conditional may be predicted, and the "read B" may be
      speculatively moved up to before reading the value A.  So we require the
      user to insert a smp_rmb() between the two accesses to be correct:
      
          read A;
          if (A == 1)
              smp_rmb()
              read B
      
      Alpha is further special in that it can break that ordering even if the
      *address* of B depends on the read of A, because the cacheline that is
      read later may be stale unless you have a memory barrier in between the
      pointer read and the read of the value behind a pointer:
      
          read ptr
          read offset(ptr)
      
      whereas all other weakly ordered architectures guarantee that the data
      dependency (as opposed to just a control dependency) will order the two
      accesses.  As a result, alpha needs a "smp_read_barrier_depends()" in
      between those two reads for them to be ordered.
      
      The coontrol dependency that "READ_ONCE_CTRL()" and "atomic_read_ctrl()"
      had was a control dependency to a subsequent *write*, however, and
      nobody can finalize such a subsequent write without having actually done
      the read.  And were you to write such a value to a "stale" cacheline
      (the way the unordered reads came to be), that would seem to lose the
      write entirely.
      
      So the things that make alpha able to re-order reads even more
      aggressively than other weak architectures do not seem to be relevant
      for a subsequent write.  Alpha memory ordering may be strange, but
      there's no real indication that it is *that* strange.
      
      Also, the alpha architecture reference manual very explicitly talks
      about the definition of "Dependence Constraints" in section 5.6.1.7,
      where a preceding read dominates a subsequent write.
      
      Such a dependence constraint admittedly does not impose a BEFORE (alpha
      architecture term for globally visible ordering), but it does guarantee
      that there can be no "causal loop".  I don't see how you could avoid
      such a loop if another cpu could see the stored value and then impact
      the value of the first read.  Put another way: the read and the write
      could not be seen as being out of order wrt other cpus.
      
      So I do not see how these "x_ctrl()" functions can currently be necessary.
      
      I may have to eat my words at some point, but in the absense of clear
      proof that alpha actually needs this, or indeed even an explanation of
      how alpha could _possibly_ need it, I do not believe these functions are
      called for.
      
      And if it turns out that alpha really _does_ need a barrier for this
      case, that barrier still should not be "smp_read_barrier_depends()".
      We'd have to make up some new speciality barrier just for alpha, along
      with the documentation for why it really is necessary.
      
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul E McKenney <paulmck@us.ibm.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      105ff3cb
  14. 06 Oct, 2015 1 commit
  15. 23 Sep, 2015 2 commits
  16. 12 Aug, 2015 1 commit
    • Will Deacon's avatar
      locking/atomics: Add _{acquire|release|relaxed}() variants of some atomic operations · 654672d4
      Will Deacon authored
      
      
      Whilst porting the generic qrwlock code over to arm64, it became
      apparent that any portable locking code needs finer-grained control of
      the memory-ordering guarantees provided by our atomic routines.
      
      In particular: xchg, cmpxchg, {add,sub}_return are often used in
      situations where full barrier semantics (currently the only option
      available) are not required. For example, when a reader increments a
      reader count to obtain a lock, checking the old value to see if a writer
      was present, only acquire semantics are strictly needed.
      
      This patch introduces three new ordering semantics for these operations:
      
        - *_relaxed: No ordering guarantees. This is similar to what we have
                     already for the non-return atomics (e.g. atomic_add).
      
        - *_acquire: ACQUIRE semantics, similar to smp_load_acquire.
      
        - *_release: RELEASE semantics, similar to smp_store_release.
      
      In memory-ordering speak, this means that the acquire/release semantics
      are RCpc as opposed to RCsc. Consequently a RELEASE followed by an
      ACQUIRE does not imply a full barrier, as already documented in
      memory-barriers.txt.
      
      Currently, all the new macros are conditionally mapped to the full-mb
      variants, however if the *_relaxed version is provided by the
      architecture, then the acquire/release variants are constructed by
      supplementing the relaxed routine with an explicit barrier.
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Waiman.Long@hp.com
      Cc: paulmck@linux.vnet.ibm.com
      Link: http://lkml.kernel.org/r/1438880084-18856-2-git-send-email-will.deacon@arm.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      654672d4
  17. 27 Jul, 2015 2 commits
  18. 13 Aug, 2014 1 commit
    • Peter Zijlstra's avatar
      locking: Remove deprecated smp_mb__() barriers · 2e39465a
      Peter Zijlstra authored
      
      
      Its been a while and there are no in-tree users left, so remove the
      deprecated barriers.
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Chen, Gong <gong.chen@linux.intel.com>
      Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: John Sullivan <jsrhbz@kanargh.force9.co.uk>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      2e39465a
  19. 18 Apr, 2014 1 commit
    • Peter Zijlstra's avatar
      arch: Prepare for smp_mb__{before,after}_atomic() · febdbfe8
      Peter Zijlstra authored
      
      
      Since the smp_mb__{before,after}*() ops are fundamentally dependent on
      how an arch can implement atomics it doesn't make sense to have 3
      variants of them. They must all be the same.
      
      Furthermore, the 3 variants suggest they're only valid for those 3
      atomic ops, while we have many more where they could be applied.
      
      So move away from
      smp_mb__{before,after}_{atomic,clear}_{dec,inc,bit}() and reduce the
      interface to just the two: smp_mb__{before,after}_atomic().
      
      This patch prepares the way by introducing default implementations in
      asm-generic/barrier.h that default to a full barrier and providing
      __deprecated inlines for the previous 6 barriers if they're not
      provided by the arch.
      
      This should allow for a mostly painless transition (lots of deprecated
      warns in the interim).
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Acked-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/n/tip-wr59327qdyi9mbzn6x937s4e@git.kernel.org
      
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: "Chen, Gong" <gong.chen@linux.intel.com>
      Cc: John Sullivan <jsrhbz@kanargh.force9.co.uk>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
      Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Cc: "Theodore Ts'o" <tytso@mit.edu>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      febdbfe8
  20. 09 Oct, 2012 1 commit
    • Shaohua Li's avatar
      atomic: implement generic atomic_dec_if_positive() · e79bee24
      Shaohua Li authored
      
      
      The x86 implementation of atomic_dec_if_positive is quite generic, so make
      it available to all architectures.
      
      This is needed for "swap: add a simple detector for inappropriate swapin
      readahead".
      
      [akpm@linux-foundation.org: do the "#define foo foo" trick in the conventional manner]
      Signed-off-by: default avatarShaohua Li <shli@fusionio.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e79bee24
  21. 07 Mar, 2012 1 commit
  22. 26 Jul, 2011 4 commits
  23. 20 Jul, 2011 1 commit
  24. 28 May, 2011 1 commit
  25. 12 Nov, 2010 1 commit
    • Eric Dumazet's avatar
      atomic: add atomic_inc_not_zero_hint() · 3f9d35b9
      Eric Dumazet authored
      
      
      Followup of perf tools session in Netfilter WorkShop 2010
      
      In the network stack we make high usage of atomic_inc_not_zero() in
      contexts we know the probable value of atomic before increment (2 for udp
      sockets for example)
      
      Using a special version of atomic_inc_not_zero() giving this hint can help
      processor to use less bus transactions.
      
      On x86 (MESI protocol) for example, this avoids entering Shared state,
      because "lock cmpxchg" issues an RFO (Read For Ownership)
      
      akpm: Adds a new include/linux/atomic.h.  This means that new code should
      henceforth include linux/atomic.h and not asm/atomic.h.  The presence of
      include/linux/atomic.h will in fact cause checkpatch.pl to warn about use
      of asm/atomic.h.  The new include/linux/atomic.h becomes the place where
      arch-neutral atomic_t code should be placed.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Arnaldo Carvalho de Melo <acme@infradead.org>
      Cc: David Miller <davem@davemloft.net>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: Nick Piggin <npiggin@kernel.dk>
      Reviewed-by: default avatar"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3f9d35b9