1. 23 3月, 2011 1 次提交
  2. 19 3月, 2011 2 次提交
  3. 18 3月, 2011 1 次提交
  4. 17 3月, 2011 4 次提交
  5. 16 3月, 2011 1 次提交
  6. 11 3月, 2011 2 次提交
    • M
      futex: Sanitize futex ops argument types · 8d7718aa
      Michel Lespinasse 提交于
      Change futex_atomic_op_inuser and futex_atomic_cmpxchg_inatomic
      prototypes to use u32 types for the futex as this is the data type the
      futex core code uses all over the place.
      Signed-off-by: NMichel Lespinasse <walken@google.com>
      Cc: Darren Hart <darren@dvhart.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <20110311025058.GD26122@google.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      8d7718aa
    • M
      futex: Sanitize cmpxchg_futex_value_locked API · 37a9d912
      Michel Lespinasse 提交于
      The cmpxchg_futex_value_locked API was funny in that it returned either
      the original, user-exposed futex value OR an error code such as -EFAULT.
      This was confusing at best, and could be a source of livelocks in places
      that retry the cmpxchg_futex_value_locked after trying to fix the issue
      by running fault_in_user_writeable().
          
      This change makes the cmpxchg_futex_value_locked API more similar to the
      get_futex_value_locked one, returning an error code and updating the
      original value through a reference argument.
      Signed-off-by: NMichel Lespinasse <walken@google.com>
      Acked-by: Chris Metcalf <cmetcalf@tilera.com>  [tile]
      Acked-by: Tony Luck <tony.luck@intel.com>  [ia64]
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: Michal Simek <monstr@monstr.eu>  [microblaze]
      Acked-by: David Howells <dhowells@redhat.com> [frv]
      Cc: Darren Hart <darren@dvhart.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      LKML-Reference: <20110311024851.GC26122@google.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      37a9d912
  7. 28 2月, 2011 1 次提交
  8. 18 2月, 2011 1 次提交
  9. 16 2月, 2011 1 次提交
    • D
      sparc64: Fix NMI startup bug which also breaks perf. · b62818e5
      David S. Miller 提交于
      Doing NMI startup as an early initcall doesn't work because we need
      to have SMP started up by then.
      
      So we'd only NMI startup one cpu, which causes perf PMU grab to
      BUG because the nmi_active count isn't what it's supposed to be.
      
      This also points out that we don't have proper CPU up/down notifiers
      for the NMI code which will need to be fixed at some point.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b62818e5
  10. 27 1月, 2011 5 次提交
  11. 05 1月, 2011 1 次提交
  12. 04 1月, 2011 1 次提交
    • S
      sparc: fix sparse warnings in arch/sparc/prom for 32 bit build · 5f66dd35
      Sam Ravnborg 提交于
      Fix following sparse warnings:
      arch/sparc/prom/bootstr_32.c:32:35: warning: Using plain integer as NULL pointer
      arch/sparc/prom/memory.c:61:13: warning: symbol 'prom_meminit' was not declared. Should it be static?
      arch/sparc/prom/misc_32.c:74:1: error: symbol 'prom_halt' redeclared with different type (originally declared at arch/sparc/include/asm/oplib_32.h:67) - different modifiers
      arch/sparc/prom/ranges.c:16:26: warning: symbol 'promlib_obio_ranges' was not declared. Should it be static?
      arch/sparc/prom/ranges.c:17:5: warning: symbol 'num_obio_ranges' was not declared. Should it be static?
      arch/sparc/prom/ranges.c:39:1: warning: symbol 'prom_adjust_ranges' was not declared. Should it be static?
      arch/sparc/prom/ranges.c:69:13: warning: symbol 'prom_ranges_init' was not declared. Should it be static?
      arch/sparc/prom/tree_32.c:286:22: warning: Using plain integer as NULL pointer
      arch/sparc/prom/tree_32.c:286:38: warning: Using plain integer as NULL pointer
      
      None of the warnings indicated any serious issues.
      
      We are now sparse clean for 32 bit build in arch/sparc/prom.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5f66dd35
  13. 03 1月, 2011 4 次提交
  14. 17 12月, 2010 1 次提交
  15. 13 12月, 2010 1 次提交
  16. 01 12月, 2010 3 次提交
  17. 26 11月, 2010 1 次提交
  18. 18 11月, 2010 1 次提交
  19. 17 11月, 2010 4 次提交
  20. 30 10月, 2010 1 次提交
  21. 28 10月, 2010 2 次提交
  22. 27 10月, 2010 1 次提交