1. 02 2月, 2008 6 次提交
    • T
      futex: Add bitset conditional wait/wakeup functionality · cd689985
      Thomas Gleixner 提交于
      To allow the implementation of optimized rw-locks in user space, glibc
      needs a possibility to select waiters for wakeup depending on a bitset
      mask.
      
      This requires two new futex OPs: FUTEX_WAIT_BITS and FUTEX_WAKE_BITS
      These OPs are basically the same as FUTEX_WAIT and FUTEX_WAKE plus an
      additional argument - a bitset. Further the FUTEX_WAIT_BITS OP is
      expecting an absolute timeout value instead of the relative one, which
      is used for the FUTEX_WAIT OP.
      
      FUTEX_WAIT_BITS calls into the kernel with a bitset. The bitset is
      stored in the futex_q structure, which is used to enqueue the waiter
      into the hashed futex waitqueue.
      
      FUTEX_WAKE_BITS also calls into the kernel with a bitset. The wakeup
      function logically ANDs the bitset with the bitset stored in each
      waiters futex_q structure. If the result is zero (i.e. none of the set
      bits in the bitsets is matching), then the waiter is not woken up. If
      the result is not zero (i.e. one of the set bits in the bitsets is
      matching), then the waiter is woken.
      
      The bitset provided by the caller must be non zero. In case the
      provided bitset is zero the kernel returns EINVAL.
      
      Internaly the new OPs are only extensions to the existing FUTEX_WAIT
      and FUTEX_WAKE functions. The existing OPs hand a bitset with all bits
      set into the futex_wait() and futex_wake() functions.
      Signed-off-by: NThomas Gleixner <tgxl@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cd689985
    • T
      futex: Remove warn on in return fixup path · 83e96c60
      Thomas Gleixner 提交于
      The WARN_ON() in the fixup return path of futex_lock_pi() can
      trigger with false positives.
      
      The following scenario happens:
      t1 holds the futex and t2 and t3 are blocked on the kernel side rt_mutex.
      t1 releases the futex (and the rt_mutex) and assigned t2 to be the next
      owner of the futex.
      
      t2 is interrupted and returns w/o acquiring the rt_mutex, before t1 can
      release the rtmutex.
      
      t1 releases the rtmutex and t3 becomes the pending owner of the rtmutex.
      
      t2 notices that it is the designated owner (user space variable) and
      fails to acquire the rt_mutex via trylock, because it is not allowed to
      steal the rt_mutex from t3. Now it looks at the rt_mutex pending owner (t3)
      and assigns the futex and the pi_state to it.
      
      During the fixup t4 steals the rtmutex from t3.
      
      t2 returns from the fixup and the owner of the rt_mutex has changed from
      t3 to t4.
      
      There is no need to do another round of fixups from t2. The important
      part (t2 is not returning as the user space visible owner) is
      done. The further fixups are done, before either t3 or t4 return to
      user space.
      
      For the user space it is not relevant which task (t3 or t4) is the real
      owner, as long as those are both in the kernel, which is guaranteed by
      the serialization of the hash bucket lock. Both tasks (which ever returns
      first to userspace - t4 because it locked the rt_mutex or t3 due to a signal)
      are going through the lock_futex_pi() return path where the ownership is
      fixed before the return to user space.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      83e96c60
    • T
      x86: replace LOCK_PREFIX in futex.h · 9d55b992
      Thomas Gleixner 提交于
      The exception fixup for the futex macros __futex_atomic_op1/2 and
      futex_atomic_cmpxchg_inatomic() is missing an entry when the lock
      prefix is replaced by a NOP via SMP alternatives.
      
      Chuck Ebert tracked this down from the information provided in:
      https://bugzilla.redhat.com/show_bug.cgi?id=429412
      
      A possible solution would be to add another fixup after the
      LOCK_PREFIX, so both the LOCK and NOP case have their own entry in the
      exception table, but it's not really worth the trouble.
      
      Simply replace LOCK_PREFIX with lock and keep those untouched by SMP
      alternatives.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9d55b992
    • T
      tick-sched: add more debug information · 5df7fa1c
      Thomas Gleixner 提交于
      To allow better diagnosis of tick-sched related, especially NOHZ
      related problems, we need to know when the last wakeup via an irq
      happened and when the CPU left the idle state.
      
      Add two fields (idle_waketime, idle_exittime) to the tick_sched
      structure and add them to the timer_list output.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      5df7fa1c
    • T
      timekeeping: update xtime_cache when time(zone) changes · 1001d0a9
      Thomas Gleixner 提交于
      xtime_cache needs to be updated whenever xtime and or wall_to_monotic
      are changed. Otherwise users of xtime_cache might see a stale (and in
      the case of timezone changes utterly wrong) value until the next
      update happens.
      
      Fixup the obvious places, which miss this update.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NJohn Stultz <johnstul@us.ibm.com>
      Tested-by: NDhaval Giani <dhaval@linux.vnet.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1001d0a9
    • P
      hrtimer: fix hrtimer_init_sleeper() users · 3588a085
      Peter Zijlstra 提交于
      this patch:
      
       commit 37bb6cb4
       Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
       Date:   Fri Jan 25 21:08:32 2008 +0100
      
           hrtimer: unlock hrtimer_wakeup
      
      Broke hrtimer_init_sleeper() users. It forgot to fix up the futex
      caller of this function to detect the failed queueing and messed up
      the do_nanosleep() caller in that it could leak a TASK_INTERRUPTIBLE
      state.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3588a085
  2. 01 2月, 2008 34 次提交