From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755966AbdCGSrs (ORCPT ); Tue, 7 Mar 2017 13:47:48 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:43514 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755386AbdCGSno (ORCPT ); Tue, 7 Mar 2017 13:43:44 -0500 Date: Tue, 7 Mar 2017 18:59:57 +0100 (CET) From: Thomas Gleixner To: Peter Zijlstra cc: 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, dvhart@infradead.org Subject: Re: [PATCH -v5 12/14] futex,rt_mutex: Restructure rt_mutex_finish_proxy_lock() In-Reply-To: <20170307175726.GD3312@twins.programming.kicks-ass.net> Message-ID: References: <20170304092717.762954142@infradead.org> <20170304093559.546712677@infradead.org> <20170307175726.GD3312@twins.programming.kicks-ass.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 7 Mar 2017, Peter Zijlstra wrote: > On Tue, Mar 07, 2017 at 03:18:46PM +0100, Thomas Gleixner wrote: > > On Sat, 4 Mar 2017, Peter Zijlstra wrote: > > > +/** > > > + * rt_mutex_cleanup_proxy_lock() - Cleanup failed lock acquisition > > > + * @lock: the rt_mutex we were woken on > > > + * @waiter: the pre-initialized rt_mutex_waiter > > > + * > > > + * Clean up the failed lock acquisition as per rt_mutex_wait_proxy_lock(). > > > + * > > > + * Returns: > > > + * true - did the cleanup, we done. > > > + * false - we acquired the lock after rt_mutex_wait_proxy_lock() returned, > > > + * caller should disregards its return value. > > > > Hmm. How would that happen? Magic owner assignement to a non waiter? The > > callsite only calls here in the failed case. > > Ah, but until the remove_waiter() below, we _still_ are a waiter, and > thus can get assigned ownership. > > > > + * > > > + * Special API call for PI-futex support > > > + */ > > > +bool rt_mutex_cleanup_proxy_lock(struct rt_mutex *lock, > > > + struct rt_mutex_waiter *waiter) > > > +{ > > > + bool cleanup = false; > > > + > > > + raw_spin_lock_irq(&lock->wait_lock); > > > + /* > > > + * If we acquired the lock, no cleanup required. > > > + */ > > > + if (rt_mutex_owner(lock) != current) { > > > + remove_waiter(lock, waiter); > > See, up till this point, we still a waiter and any unlock can see us > being one. Hmm, true. So the comments should explain that Thanks, tglx