From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754176AbbLTHl7 (ORCPT ); Sun, 20 Dec 2015 02:41:59 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:43304 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754102AbbLTHl6 (ORCPT ); Sun, 20 Dec 2015 02:41:58 -0500 Date: Sat, 19 Dec 2015 23:41:55 -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 3/5] futex: Document pi_state refcounting in requeue code Message-ID: <20151220074155.GM7244@malice.jf.intel.com> References: <20151219200501.563704646@linutronix.de> <20151219200607.335938312@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151219200607.335938312@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:39PM -0000, Thomas Gleixner wrote: > Documentation of the pi_state refcounting in the requeue code is non > existent. Add it. > OK, one nitpic on this one I guess - 80 characters is pretty narrow as it is in my humble opinion, could we expand the newly added comment blocks to use all of the 80 character limit? > Signed-off-by: Thomas Gleixner > --- > kernel/futex.c | 36 +++++++++++++++++++++++++++++++++--- > 1 file changed, 33 insertions(+), 3 deletions(-) > > --- a/kernel/futex.c > +++ b/kernel/futex.c ... > - /* We got the lock. */ > + /* > + * We got the lock. We do neither drop > + * the refcount on pi_state nor clear > + * this->pi_state because the waiter > + * needs the pi_state for cleaning up > + * the user space value. It will drop > + * the refcount after doing so. > + */ > requeue_pi_wake_futex(this, &key2, hb2); > drop_count++; > continue; > } else if (ret) { > - /* -EDEADLK */ > + /* > + * rt_mutex_start_proxy_lock() > + * detected a potential deadlock when > + * we tried to queue that waiter. Drop > + * the pi_state reference which we > + * took above and remove the pointer > + * to the state from the waiters > + * futex_q object. > + */ Especially the two paragraphs above ^ -- Darren Hart Intel Open Source Technology Center