1. 10 Aug, 2009 4 commits
    • Darren Hart's avatar
      futex: Fix handling of bad requeue syscall pairing · 392741e0
      Darren Hart authored
      If futex_requeue(requeue_pi=1) finds a futex_q that was created by a call
      other the futex_wait_requeue_pi(), the q.rt_waiter may be null.  If so,
      this will result in an oops from the following call graph:
      
      futex_requeue()
        rt_mutex_start_proxy_lock()
          task_blocks_on_rt_mutex()
            waiter->task dereference
              OOPS
      
      We currently WARN_ON() if this is detected, clearly this is inadequate.
      If we detect a mispairing in futex_requeue(), bail out, seding -EINVAL to
      user-space.
      
      V2: Fix parenthesis warnings.
      Signed-off-by: default avatarDarren Hart <dvhltc@us.ibm.com>
      Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: John Kacur <jkacur@redhat.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Dinakar Guniguntala <dino@in.ibm.com>
      Cc: John Stultz <johnstul@linux.vnet.ibm.com>
      LKML-Reference: <4A7CA8C0.7010809@us.ibm.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      392741e0
    • Dinakar Guniguntala's avatar
      futex: Fix compat_futex to be same as futex for REQUEUE_PI · 4dc88029
      Dinakar Guniguntala authored
      Need to add the REQUEUE_PI checks to the compat_sys_futex API
      as well to ensure 32 bit requeue's work fine on a 64 bit
      system. Patch is against latest tip
      Signed-off-by: default avatarDinakar Guniguntala <dino@in.ibm.com>
      Cc: Darren Hart <dvhltc@us.ibm.com>
      LKML-Reference: <20090810130142.GA23619@in.ibm.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      4dc88029
    • Peter Zijlstra's avatar
      locking, sched: Give waitqueue spinlocks their own lockdep classes · 2fc39111
      Peter Zijlstra authored
      Give waitqueue spinlocks their own lockdep classes when they
      are initialised from init_waitqueue_head().  This means that
      struct wait_queue::func functions can operate other waitqueues.
      
      This is used by CacheFiles to catch the page from a backing fs
      being unlocked and to wake up another thread to take a copy of
      it.
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Tested-by: default avatarTakashi Iwai <tiwai@suse.de>
      Cc: linux-cachefs@redhat.com
      Cc: torvalds@osdl.org
      Cc: akpm@linux-foundation.org
      LKML-Reference: <20090810113305.17284.81508.stgit@warthog.procyon.org.uk>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      2fc39111
    • Darren Hart's avatar
      futex: Update futex_q lock_ptr on requeue proxy lock · beda2c7e
      Darren Hart authored
      futex_requeue() can acquire the lock on behalf of a waiter
      early on or during the requeue loop if it is uncontended or in
      the event of a lock steal or owner died. On wakeup, the waiter
      (in futex_wait_requeue_pi()) cleans up the pi_state owner using
      the lock_ptr to protect against concurrent access to the
      pi_state. The pi_state is hung off futex_q's on the requeue
      target futex hash bucket so the lock_ptr needs to be updated
      accordingly.
      
      The problem manifested by triggering the WARN_ON in
      lookup_pi_state() about the pid != pi_state->owner->pid.  With
      this patch, the pi_state is properly guarded against concurrent
      access via the requeue target hb lock.
      
      The astute reviewer may notice that there is a window of time
      between when futex_requeue() unlocks the hb locks and when
      futex_wait_requeue_pi() will acquire hb2->lock.  During this
      time the pi_state and uval are not in sync with the underlying
      rtmutex owner (but the uval does indicate there are waiters, so
      no atomic changes will occur in userspace).  However, this is
      not a problem. Should a contending thread enter
      lookup_pi_state() and acquire hb2->lock before the ownership is
      fixed up, it will find the pi_state hung off a waiter's
      (possibly the pending owner's) futex_q and block on the
      rtmutex.  Once futex_wait_requeue_pi() fixes up the owner, it
      will also move the pi_state from the old owner's
      task->pi_state_list to its own.
      
      v3: Fix plist lock name for application to mainline (rather
          than -rt) Compile tested against tip/v2.6.31-rc5.
      Signed-off-by: default avatarDarren Hart <dvhltc@us.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Dinakar Guniguntala <dino@in.ibm.com>
      Cc: John Stultz <johnstul@linux.vnet.ibm.com>
      LKML-Reference: <4A7F4EFF.6090903@us.ibm.com>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      beda2c7e
  2. 09 Aug, 2009 15 commits
  3. 08 Aug, 2009 10 commits
  4. 07 Aug, 2009 11 commits