1. 14 Dec, 2009 2 commits
  2. 06 Aug, 2009 1 commit
    • Darren Hart's avatar
      rtmutex: Avoid deadlock in rt_mutex_start_proxy_lock() · 1bbf2083
      Darren Hart authored
      In the event of a lock steal or owner died,
      rt_mutex_start_proxy_lock() will give the rt_mutex to the
      waiting task, but it fails to release the wait_lock. This leads
      to subsequent deadlocks when other tasks try to acquire the
      I also removed a few extra blank lines that really spaced this
      routine out. I must have been high on the \n when I wrote this
      Signed-off-by: default avatarDarren Hart <dvhltc@us.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Dinakar Guniguntala <dino@in.ibm.com>
      Cc: John Stultz <johnstul@linux.vnet.ibm.com>
      LKML-Reference: <4A79D7F1.4000405@us.ibm.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
  3. 12 Jun, 2009 1 commit
  4. 29 Apr, 2009 1 commit
  5. 06 Apr, 2009 1 commit
  6. 06 Sep, 2008 1 commit
  7. 13 Feb, 2008 1 commit
  8. 19 Oct, 2007 1 commit
  9. 16 Jul, 2007 1 commit
  10. 18 Jun, 2007 1 commit
    • Thomas Gleixner's avatar
      Revert "futex_requeue_pi optimization" · bd197234
      Thomas Gleixner authored
      This reverts commit d0aa7a70.
      It not only introduced user space visible changes to the futex syscall,
      it is also non-functional and there is no way to fix it proper before
      the 2.6.22 release.
      The breakage report ( http://lkml.org/lkml/2007/5/12/17 ) went
      unanswered, and unfortunately it turned out that the concept is not
      feasible at all.  It violates the rtmutex semantics badly by introducing
      a virtual owner, which hacks around the coupling of the user-space
      pi_futex and the kernel internal rt_mutex representation.
      At the moment the only safe option is to remove it fully as it contains
      user-space visible changes to broken kernel code, which we do not want
      to expose in the 2.6.22 release.
      The patch reverts the original patch mostly 1:1, but contains a couple
      of trivial manual cleanups which were necessary due to patches, which
      touched the same area of code later.
      Verified against the glibc tests and my own PI futex tests.
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Acked-by: default avatarUlrich Drepper <drepper@redhat.com>
      Cc: Pierre Peiffer <pierre.peiffer@bull.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  11. 09 Jun, 2007 2 commits
  12. 09 May, 2007 1 commit
  13. 16 Feb, 2007 1 commit
  14. 29 Sep, 2006 1 commit
    • Steven Rostedt's avatar
      [PATCH] clean up and remove some extra spinlocks from rtmutex · db630637
      Steven Rostedt authored
      Oleg brought up some interesting points about grabbing the pi_lock for some
      protections.  In this discussion, I realized that there are some places
      that the pi_lock is being grabbed when it really wasn't necessary.  Also
      this patch does a little bit of clean up.
      This patch basically does three things:
      1) renames the "boost" variable to "chain_walk".  Since it is used in
         the debugging case when it isn't going to be boosted.  It better
         describes what the test is going to do if it succeeds.
      2) moves get_task_struct to just before the unlocking of the wait_lock.
         This removes duplicate code, and makes it a little easier to read.  The
         owner wont go away while either the pi_lock or the wait_lock are held.
      3) removes the pi_locking and owner blocked checking completely from the
         debugging case.  This is because the grabbing the lock and doing the
         check, then releasing the lock is just so full of races.  It's just as
         good to go ahead and call the pi_chain_walk function, since after
         releasing the lock the owner can then block anyway, and we would have
         missed that.  For the debug case, we really do want to do the chain walk
         to test for deadlocks anyway.
      [oleg@tv-sign.ru: more of the same]
      Signed-of-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Oleg Nesterov <oleg@tv-sign.ru>
      Cc: Esben Nielsen <nielsen.esben@googlemail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  15. 31 Jul, 2006 1 commit
  16. 03 Jul, 2006 2 commits
    • Ingo Molnar's avatar
      [PATCH] sched: cleanup, remove task_t, convert to struct task_struct · 36c8b586
      Ingo Molnar authored
      cleanup: remove task_t and convert all the uses to struct task_struct. I
      introduced it for the scheduler anno and it was a mistake.
      Conversion was mostly scripted, the result was reviewed and all
      secondary whitespace and style impact (if any) was fixed up by hand.
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    • Ingo Molnar's avatar
      [PATCH] lockdep: better lock debugging · 9a11b49a
      Ingo Molnar authored
      Generic lock debugging:
       - generalized lock debugging framework. For example, a bug in one lock
         subsystem turns off debugging in all lock subsystems.
       - got rid of the caller address passing (__IP__/__IP_DECL__/etc.) from
         the mutex/rtmutex debugging code: it caused way too much prototype
         hackery, and lockdep will give the same information anyway.
       - ability to do silent tests
       - check lock freeing in vfree too.
       - more finegrained debugging options, to allow distributions to
         turn off more expensive debugging features.
      There's no separate 'held mutexes' list anymore - but there's a 'held locks'
      stack within lockdep, which unifies deadlock detection across all lock
      classes.  (this is independent of the lockdep validation stuff - lockdep first
      checks whether we are holding a lock already)
      Here are the current debugging options:
      which do:
       config DEBUG_MUTEXES
                bool "Mutex debugging, basic checks"
       config DEBUG_LOCK_ALLOC
               bool "Detect incorrect freeing of live mutexes"
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  17. 28 Jun, 2006 4 commits