From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935158AbcLQANh (ORCPT ); Fri, 16 Dec 2016 19:13:37 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:46850 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934191AbcLQANZ (ORCPT ); Fri, 16 Dec 2016 19:13:25 -0500 Date: Fri, 16 Dec 2016 16:13:10 -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 03/10] futex: Cleanup variable names for futex_top_waiter() Message-ID: <20161217001310.GF62123@f23x64.localdomain> References: <20161213083638.938898295@infradead.org> <20161213085730.211285865@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161213085730.211285865@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:41AM +0100, Peter Zijlstra wrote: > futex_top_waiter() returns the top-waiter on the pi_mutex. Assinging > this to a variable 'match' totally obscures the code. > Yes please. One wording nit... > Signed-off-by: Peter Zijlstra (Intel) > --- > kernel/futex.c | 30 +++++++++++++++--------------- > 1 file changed, 15 insertions(+), 15 deletions(-) > > --- a/kernel/futex.c > +++ b/kernel/futex.c > @@ -1317,11 +1317,11 @@ static int wake_futex_pi(u32 __user *uad > > /* > * It is possible that the next waiter (the one that brought > - * this owner to the kernel) timed out and is no longer > + * top_waiter owner to the kernel) timed out and is no longer > * waiting on the lock. > */ This breaks my parser (and did before too). Consider: /* * It is possible that the next waiter (that caused top_waiter to call * into the kernel) has since timed out and is no longer waiting on the * lock. */ Is that clearer? -- Darren Hart Intel Open Source Technology Center