lkml.org 
[lkml]   [2017]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH -v6 04/13] futex,rt_mutex: Provide futex specific rt_mutex API
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@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

\
 
 \ /
  Last update: 2017-03-25 01:38    [W:0.276 / U:0.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site