Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1237917imm; Wed, 23 May 2018 12:35:13 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqu0hwqUAevEWQSg/C7svAZIdZfATUhkf5t2Q5OqPw91TPiaZOWPliIxTrT4oRemBOgY8JR X-Received: by 2002:a63:711e:: with SMTP id m30-v6mr3272314pgc.90.1527104113513; Wed, 23 May 2018 12:35:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527104113; cv=none; d=google.com; s=arc-20160816; b=sQpkHNf1N9bv/fioGlcLLmHzjOD0eVISEWdQGfQRe5qfFT1CKYll7xVaQuJLkrO4Bc vFxgnTpHkppwJGzRQk38oUfzni/3qoYDNrWN7vcSYWQ1SJ9pRqgY5OCz7GEm96eOAAxz vc2HRoKniUpwS3SqtvrfRLDs338Sq5QWJP1o7qaNncyfMFrlDg0BRqer88OL2Le2g82o 8qOy7Jb/eGI2Q6/wzOZGXzM4RhTeR/gMmR5NbPlq0DLkXcxSxAhymg9XWqBafSIj2JpB evQ90+2Fonkb3jplYvO2dfUedjzvaPc06nsop4ob/5w+sr6iowkjV8xdVcoIt25jPPak iYTQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:user-agent:in-reply-to :content-disposition:mime-version:references:reply-to:subject:cc:to :from:date:arc-authentication-results; bh=lQNlTquebVO8yQtZVDsnH9XsI8jhvw5zuIvY8hg5JIk=; b=p2fizvpnnRQnY3nGp0upQm7LcBKFDT0xvP2nG9Lyz2G9aLSNgizmSzObofbKbnKMvJ lFEGAryx9q2AOjGGDdBORwFbjKjsFHNNqjLkIfRNIbNquhA+E2ottcsCnWnsd6xGbYcg CnBfgystqPTW/AB8YcBYOFqYJ/UCIXAXvZLx+MsGk77PBZBd1i6bW1gv8XdB0j/hMyi/ vdYaNGb8ker7vZpXLbsH+mlw1mAq6rMrTEGu4dkMrUQ1PUpWMgdqKIdM7NV72oSpVP5+ 1nl+nRK0AxY3VVhF6eHnmxMtXuFy31deqMt3mhKjIArej4wu8F4iRM+mmwTryMDQ0OrQ +K0Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g59-v6si19607712plb.381.2018.05.23.12.34.58; Wed, 23 May 2018 12:35:13 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934748AbeEWTdl (ORCPT + 99 others); Wed, 23 May 2018 15:33:41 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:36382 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S934690AbeEWTdc (ORCPT ); Wed, 23 May 2018 15:33:32 -0400 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4NJTFlu103073 for ; Wed, 23 May 2018 15:33:32 -0400 Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by mx0b-001b2d01.pphosted.com with ESMTP id 2j5bnhym9h-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 23 May 2018 15:33:31 -0400 Received: from localhost by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 23 May 2018 13:33:30 -0600 Received: from b01cxnp22033.gho.pok.ibm.com (9.57.198.23) by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Wed, 23 May 2018 13:33:27 -0600 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp22033.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w4NJMAN859572328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 23 May 2018 19:22:10 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 26C5DB2067; Wed, 23 May 2018 16:23:59 -0400 (EDT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 06C24B205F; Wed, 23 May 2018 16:23:59 -0400 (EDT) Received: from paulmck-ThinkPad-W541 (unknown [9.70.82.108]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP; Wed, 23 May 2018 16:23:58 -0400 (EDT) Received: by paulmck-ThinkPad-W541 (Postfix, from userid 1000) id 212ED16C5DDA; Wed, 23 May 2018 12:23:49 -0700 (PDT) Date: Wed, 23 May 2018 12:23:49 -0700 From: "Paul E. McKenney" To: Joel Fernandes Cc: linux-kernel@vger.kernel.org, "Joel Fernandes (Google)" , Boqun Feng , byungchul.park@lge.com, Ingo Molnar , Josh Triplett , kernel-team@android.com, Lai Jiangshan , Mathieu Desnoyers , Peter Zilstra , Steven Rostedt Subject: Re: [PATCH 3/4] rcu: Use better variable names in funnel locking loop Reply-To: paulmck@linux.vnet.ibm.com References: <20180523063815.198302-1-joel@joelfernandes.org> <20180523063815.198302-4-joel@joelfernandes.org> <20180523160617.GM3803@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180523160617.GM3803@linux.vnet.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 18052319-8235-0000-0000-00000D8F3D74 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00009073; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000261; SDB=6.01036623; UDB=6.00530321; IPR=6.00815751; MB=3.00021262; MTD=3.00000008; XFM=3.00000015; UTC=2018-05-23 19:33:30 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18052319-8236-0000-0000-0000411CA5EC Message-Id: <20180523192349.GA5845@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-23_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1805230190 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 23, 2018 at 09:06:17AM -0700, Paul E. McKenney wrote: > On Tue, May 22, 2018 at 11:38:14PM -0700, Joel Fernandes wrote: > > From: "Joel Fernandes (Google)" > > > > The funnel locking loop in rcu_start_this_gp uses rcu_root as a > > temporary variable while walking the combining tree. This causes a > > tiresome exercise of a code reader reminding themselves that rcu_root > > may not be root. Lets just call it rnp, and rename other variables as > > well to be more appropriate. > > > > Original patch: https://patchwork.kernel.org/patch/10396577/ > > > > Signed-off-by: Joel Fernandes > > Signed-off-by: Joel Fernandes (Google) > > I used to have double Signed-off-by back when I was seconded to Linaro. > But I am guessing that you want the second and don't need the first > one. Unless you tell me otherwise, I will remove the first one on > my next rebase. > > Anyway, the new variable names are much more clear, good stuff, > queued for further review and testing, thank you! And it looks to me like I should fold in the patchlet below to change to rnp_start in a comment. Please let me know if this would mess things up. Thanx, Paul ------------------------------------------------------------------------ commit 94ce05d9d110b8c34eca6641ca5221c1b150e99f Author: Paul E. McKenney Date: Wed May 23 12:22:01 2018 -0700 fixup! rcu: Use better variable names in funnel locking loop Signed-off-by: Paul E. McKenney diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 65e49282429c..fdba8ab95e2c 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -1550,11 +1550,11 @@ static bool rcu_start_this_gp(struct rcu_node *rnp_start, struct rcu_data *rdp, /* * Use funnel locking to either acquire the root rcu_node * structure's lock or bail out if the need for this grace period - * has already been recorded -- or has already started. If there - * is already a grace period in progress in a non-leaf node, no - * recording is needed because the end of the grace period will - * scan the leaf rcu_node structures. Note that rnp->lock must - * not be released. + * has already been recorded -- or if that grace period has in + * fact already started. If there is already a grace period in + * progress in a non-leaf node, no recording is needed because the + * end of the grace period will scan the leaf rcu_node structures. + * Note that rnp_start->lock must not be released. */ raw_lockdep_assert_held_rcu_node(rnp_start); trace_rcu_this_gp(rnp_start, rdp, gp_seq_req, TPS("Startleaf"));