Re: [PATCH -v6 04/13] futex,rt_mutex: Provide futex specific rt_mutex API

[Darren Hart]

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) <peterz@xxxxxxxxxxxxx>

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