lkml.org 
[lkml]   [2016]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] kernel/futex: handle the case where we got a "late" waiter
    On Tue, 19 Apr 2016, Davidlohr Bueso wrote:
    > On Fri, 15 Apr 2016, Sebastian Andrzej Siewior wrote:
    >
    > > futex_unlock_pi() gets uval before taking the hb lock. Now imagine
    > > someone in futex_lock_pi() took the lock. While futex_unlock_pi() waits
    > > for the hb lock, the LOCK_PI sets FUTEX_WAITERS and drops the lock.
    > > Now, futex_unlock_pi() figures out that there is waiter and invokes
    > > wake_futex_pi() with the old uval which does not yet have FUTEX_WAITERS
    > > set. This flaw lets cmpxchg_futex_value_locked() fail and return -EINVAL.
    >
    > Hmm but if we're calling futex_unlock_pi() in the first place, doesn't that
    > indicate that the uval already has FUTEX_WAITERS and therefore failed the
    > TID->0 transition in userland? That or the thread is bogusly unlocking a
    > lock that it doesn't own.

    It can be called unconditionally w/o trying the TID->0 transition in user
    space first and we should handle that case.

    Thanks,

    tglx

    \
     
     \ /
      Last update: 2016-04-20 10:01    [W:5.471 / U:0.116 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site