From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932164AbbLTFPd (ORCPT ); Sun, 20 Dec 2015 00:15:33 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:35080 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750773AbbLTFPc (ORCPT ); Sun, 20 Dec 2015 00:15:32 -0500 Date: Sat, 19 Dec 2015 21:15:24 -0800 From: Darren Hart To: Thomas Gleixner Cc: LKML , Ingo Molnar , Peter Zijlstra , Darren Hart , Davidlohr Bueso , Bhuvanesh_Surachari@mentor.com, Andy Lowe Subject: Re: [patch 5/5] futex: Cleanup the goto confusion in requeue_pi() Message-ID: <20151220051524.GH7244@malice.jf.intel.com> References: <20151219200501.563704646@linutronix.de> <20151219200607.526665141@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151219200607.526665141@linutronix.de> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Dec 19, 2015 at 08:07:41PM -0000, Thomas Gleixner wrote: > out_unlock: does not only drop the locks, it also drops the refcount > on the pi_state. Really intuitive. > > Move the label after the put_pi_state() call and use 'break' in the > error handling path of the requeue loop. > > Signed-off-by: Thomas Gleixner > --- > kernel/futex.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > --- a/kernel/futex.c > +++ b/kernel/futex.c > @@ -1842,20 +1842,21 @@ static int futex_requeue(u32 __user *uad > */ > this->pi_state = NULL; > put_pi_state(pi_state); > - goto out_unlock; > + break; > } > } > requeue_futex(this, hb1, hb2, &key2); > drop_count++; > } > > -out_unlock: > /* > * We took an extra initial reference to the pi_state either > * in futex_proxy_trylock_atomic() or in lookup_pi_state(). We > * need to drop it here again. > */ > put_pi_state(pi_state); > + > +out_unlock: > double_unlock_hb(hb1, hb2); > wake_up_q(&wake_q); > hb_waiters_dec(hb2); Thanks for catching the leak Thomas, sorry I missed it :-/ I thought you missed one point early on shortly after retry_private: where we goto out_unlock, but we haven't claimed the pi_state yet - so this appears to have been another unnecessary (harmless) put_pi_state call previously. For the series: Reviewed-by: Darren Hart As a follow-on, I think it might be worthwhile to create a symmetrical get_pi_state() to the put_pi_state(), rather than handling the atomic_inc directly. And finally, while the break; in futex_requeue works, that function is quite long and an explicit out_put_pi_state: label would make the intention clear and also avoid inadvertently breaking the implicit behavior of the break. Thanks, -- Darren Hart Intel Open Source Technology Center