On Wed, Mar 22, 2017 at 11:35:51AM +0100, Peter Zijlstra wrote: > Part of what makes futex_unlock_pi() intricate is that > rt_mutex_futex_unlock() -> rt_mutex_slowunlock() can drop > rt_mutex::wait_lock. > > This means we cannot rely on the atomicy of wait_lock, which we would > like to do in order to not rely on hb->lock so much. > > The reason rt_mutex_slowunlock() needs to drop wait_lock is because it > can race with the rt_mutex fastpath, however futexes have their own > fast path. > > Since futexes already have a bunch of separate rt_mutex accessors, > complete that set and implement a rt_mutex variant without fastpath > for them. > > Signed-off-by: Peter Zijlstra (Intel) <pet...@infradead.org>
Got to here and tried to get some testing going while I was reviewing... to find that some of the existing pi test suites LTP/realtime, are not building either. Got a fix, got it into CI, some CI issues, but no obvious fallout from this. So, review will continue... But, Peter are you testing this with anything in particular? -- Darren Hart VMware Open Source Technology Center