1. 16 6月, 2016 1 次提交
  2. 26 4月, 2016 1 次提交
  3. 23 9月, 2015 1 次提交
    • P
      atomic, arch: Audit atomic_{read,set}() · 62e8a325
      Peter Zijlstra 提交于
      This patch makes sure that atomic_{read,set}() are at least
      {READ,WRITE}_ONCE().
      
      We already had the 'requirement' that atomic_read() should use
      ACCESS_ONCE(), and most archs had this, but a few were lacking.
      All are now converted to use READ_ONCE().
      
      And, by a symmetry and general paranoia argument, upgrade atomic_set()
      to use WRITE_ONCE().
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Dmitry Vyukov <dvyukov@google.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: james.hogan@imgtec.com
      Cc: linux-kernel@vger.kernel.org
      Cc: oleg@redhat.com
      Cc: will.deacon@arm.com
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      62e8a325
  4. 27 7月, 2015 2 次提交
  5. 13 5月, 2015 1 次提交
  6. 18 4月, 2014 1 次提交
  7. 07 9月, 2013 1 次提交
    • C
      tile: rework <asm/cmpxchg.h> · 6dc9658f
      Chris Metcalf 提交于
      The macrology in cmpxchg.h was designed to allow arbitrary pointer
      and integer values to be passed through the routines.  To support
      cmpxchg() on 64-bit values on the 32-bit tilepro architecture, we
      used the idiom "(typeof(val))(typeof(val-val))".  This way, in the
      "size 8" branch of the switch, when the underlying cmpxchg routine
      returns a 64-bit quantity, we cast it first to a typeof(val-val)
      quantity (i.e. size_t if "val" is a pointer) with no warnings about
      casting between pointers and integers of different sizes, then cast
      onwards to typeof(val), again with no warnings.  If val is not a
      pointer type, the additional cast is a no-op.  We can't replace the
      typeof(val-val) cast with (for example) unsigned long, since then if
      "val" is really a 64-bit type, we cast away the high bits.
      
      HOWEVER, this fails with current gcc (through 4.7 at least) if "val"
      is a pointer to an incomplete type.  Unfortunately gcc isn't smart
      enough to realize that "val - val" will always be a size_t type
      even if it's an incomplete type pointer.
      
      Accordingly, I've reworked the way we handle the casting.  We have
      given up the ability to use cmpxchg() on 64-bit values on tilepro,
      which is OK in the kernel since we should use cmpxchg64() explicitly
      on such values anyway.  As a result, I can just use simple "unsigned
      long" casts internally.
      
      As I reworked it, I realized it would be cleaner to move the
      architecture-specific conditionals for cmpxchg and xchg out of the
      atomic.h headers and into cmpxchg, and then use the cmpxchg() and
      xchg() primitives directly in atomic.h and elsewhere.  This allowed
      the cmpxchg.h header to stand on its own without relying on the
      implicit include of it that is performed by <asm/atomic.h>.
      It also allowed collapsing the atomic_xchg/atomic_cmpxchg routines
      from atomic_{32,64}.h into atomic.h.
      
      I improved the tests that guard the allowed size of the arguments
      to the routines to use a __compiletime_error() test.  (By avoiding
      the use of BUILD_BUG, I could include cmpxchg.h into bitops.h as
      well and use the macros there, which is otherwise impossible due
      to include order dependency issues.)
      
      The tilepro _atomic_xxx internal methods were previously set up to
      take atomic_t and atomic64_t arguments, which isn't as convenient
      with the new model, so I modified them to take int or u64 arguments,
      which is consistent with how they used the arguments internally
      anyway, so provided some nice simplification there too.
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      6dc9658f
  8. 29 3月, 2012 1 次提交
  9. 27 7月, 2011 2 次提交
  10. 20 5月, 2011 1 次提交
  11. 13 5月, 2011 1 次提交
    • C
      arch/tile: finish enabling support for TILE-Gx 64-bit chip · 18aecc2b
      Chris Metcalf 提交于
      This support was partially present in the existing code (look for
      "__tilegx__" ifdefs) but with this change you can build a working
      kernel using the TILE-Gx toolchain and ARCH=tilegx.
      
      Most of these files are new, generally adding a foo_64.c file
      where previously there was just a foo_32.c file.
      
      The ARCH=tilegx directive redirects to arch/tile, not arch/tilegx,
      using the existing SRCARCH mechanism in the top-level Makefile.
      
      Changes to existing files:
      
      - <asm/bitops.h> and <asm/bitops_32.h> changed to factor the
        include of <asm-generic/bitops/non-atomic.h> in the common header.
      
      - <asm/compat.h> and arch/tile/kernel/compat.c changed to remove
        the "const" markers I had put on compat_sys_execve() when trying
        to match some recent similar changes to the non-compat execve.
        It turns out the compat version wasn't "upgraded" to use const.
      
      - <asm/opcode-tile_64.h> and <asm/opcode_constants_64.h> were
        previously included accidentally, with the 32-bit contents.  Now
        they have the proper 64-bit contents.
      
      Finally, I had to hack the existing hacky drivers/input/input-compat.h
      to add yet another "#ifdef" for INPUT_COMPAT_TEST (same as x86_64).
      Signed-off-by: NChris Metcalf <cmetcalf@tilera.com>
      Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> [drivers/input]
      18aecc2b