Hi all, This is (I think) the 4th attempt at fixing this tiny pesky issue with FUTEX_UNLOCK_PI, where we would really like to drop (and unboost) the rt_mutex without holding hb->lock.
While going through the requeue PI code and thinking about how all that worked I realized we can avoid the entire problem I've been trying to solve. That is, the 'problem' is that futex state and rt_mutex state can end up disagreeing on who is waiting for the lock and we muddle around that with intricate state. This series, well patch 8, avoids the entire problem by making sure this inconsistent state does not occur. Which then simplifies everything -- assuming I got it right of course :-) The basic idea is to, like requeue PI, break the rt_mutex_lock() function into pieces, such that we can enqueue the waiter while holding hb->lock, wait for acquisition without hb->lock and can remove the waiter, on failure, while holding hb->lock again. That way, when we drop hb->lock to wait, futex and rt_mutex wait state is consistent. In any case, it passes our inadequate testing.
