From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762314AbcLPXcA (ORCPT ); Fri, 16 Dec 2016 18:32:00 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:43554 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752900AbcLPXbx (ORCPT ); Fri, 16 Dec 2016 18:31:53 -0500 Date: Fri, 16 Dec 2016 15:31:40 -0800 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 -v4 00/10] FUTEX_UNLOCK_PI wobbles Message-ID: <20161216233140.GC62123@f23x64.localdomain> References: <20161213083638.938898295@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161213083638.938898295@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 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