From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936861AbdCYAhZ (ORCPT ); Fri, 24 Mar 2017 20:37:25 -0400 Received: from bombadil.infradead.org ([65.50.211.133]:42222 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935889AbdCYAhP (ORCPT ); Fri, 24 Mar 2017 20:37:15 -0400 Date: Fri, 24 Mar 2017 17:37:02 -0700 From: Darren Hart To: Peter Zijlstra Cc: tglx@linutronix.de, mingo@kernel.org, juri.lelli@arm.com, rostedt@goodmis.org, xlpang@redhat.com, bigeasy@linutronix.de, linux-kernel@vger.kernel.org, mathieu.desnoyers@efficios.com, jdesfossez@efficios.com, bristot@redhat.com Subject: Re: [PATCH -v6 04/13] futex,rt_mutex: Provide futex specific rt_mutex API Message-ID: <20170325003702.GA5000@fury> References: <20170322103547.756091212@infradead.org> <20170322104151.702962446@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170322104151.702962446@infradead.org> User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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) 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