On Tue, Dec 13, 2016 at 09:36:38AM +0100, Peter Zijlstra wrote: > > 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.
Oh boy, this is going to take some brain space/time. I'll comment as I work through them and ask questions - to keep the dialog going. > > 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. It passed my CI tools/testing/selftests/futex/functional/run.sh. Did you also happen to run a fuzz tester? -- Darren Hart Intel Open Source Technology Center
