Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1684689imm; Tue, 22 May 2018 07:50:20 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrViwvuqpjeD5Jh/pR6Z1vTle6/17L/aaess38jYBdSgqUc7Pb3X9GUR9mS1ywnR7vMrg4I X-Received: by 2002:a17:902:8d85:: with SMTP id v5-v6mr25109669plo.93.1527000619972; Tue, 22 May 2018 07:50:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527000619; cv=none; d=google.com; s=arc-20160816; b=IXn/PADJ9YnbIsgX83LW2JKehV2lEMS+LW8vguT31kDnZG7rVuyGm8d8cgc+jzLJzP pdX4FVNBdSdQ46JmsP5XVjh9tU+k39O03Z7ImXi+iYLD1qAQ7kZdz0NJrLNB5QpX/bXx a63XK0e8IVh7ajXA36rmGiUtaAyPQCLOAFKGDqcWn7lSg4nJmcZitI9VAIJxWRjhM71l klYv0DN69N7HJQ8GVFrleAT6lA/rBCmRzVwnFpKimj/lBbtDJhBKRoxCYImHROwrVM+L T9LXVAMJRZD/SF8NSVsG9PFvDyFqZvvUUVicimsvleRMpBB5g+ro5xKz2TaNmBah2cmo fLwA== 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=nrjiOW0zCz0f7U0bcy4ePn2y2ycLHETVMuStpDQA61I=; b=YoAaGG9hRt/rxF5+GlReTLRuZPTbqQLXVUSejrt8JH0U+/kxAgU834yg35eediQQkP VKiXAxtWyCsemnbOYQZHYAHH4QgkgWtQ4dRY3ZUOKmpQm3V+tedagiLDWBYW2r6iU/Bx T1XuDAsIVt46yXxoyf1MmJU++DI9OelB0YnUQnQZzIg4X+Yn3rnQ0mvv6eKeN/jfzn1l w1gkTH8Xef3Hn0mGKNBQKuVVsMsbYJAVRdnmnrJl2BtyiILhQd80LvuV3RcmpxbPi/GW p+a5RbJcEnHUGJ7zXhi9A3kA9+8zyZOzs+nlcrYqpXf5H5so5SToCyrQgRkGUJR881RD /BoQ== 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 x128-v6si16689616pfb.237.2018.05.22.07.50.04; Tue, 22 May 2018 07:50:19 -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 S1751429AbeEVOsm (ORCPT + 99 others); Tue, 22 May 2018 10:48:42 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:60866 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751269AbeEVOsj (ORCPT ); Tue, 22 May 2018 10:48:39 -0400 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4MEdFuG062605 for ; Tue, 22 May 2018 10:48:39 -0400 Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by mx0a-001b2d01.pphosted.com with ESMTP id 2j4mcc3bhj-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 22 May 2018 10:48:38 -0400 Received: from localhost by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 22 May 2018 08:48:37 -0600 Received: from b03cxnp08028.gho.boulder.ibm.com (9.17.130.20) by e35.co.us.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Tue, 22 May 2018 08:48:33 -0600 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b03cxnp08028.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w4MEmWu93932430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 22 May 2018 07:48:32 -0700 Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0F6D4B23FD; Tue, 22 May 2018 09:14:32 -0400 (EDT) Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B42C4B2404; Tue, 22 May 2018 09:13:19 -0400 (EDT) Received: from paulmck-ThinkPad-W541 (unknown [9.80.227.37]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP; Tue, 22 May 2018 09:12:39 -0400 (EDT) Received: by paulmck-ThinkPad-W541 (Postfix, from userid 1000) id E7DDC16C3F79; Tue, 22 May 2018 05:12:16 -0700 (PDT) Date: Tue, 22 May 2018 05:12:16 -0700 From: "Paul E. McKenney" To: Joel Fernandes Cc: Joel Fernandes , linux-kernel@vger.kernel.org, Josh Triplett , Steven Rostedt , Mathieu Desnoyers , Lai Jiangshan , byungchul.park@lge.com, kernel-team@android.com Subject: Re: [PATCH v3 4/4] rcu: Unlock non-start node only after accessing its gp_seq_needed Reply-To: paulmck@linux.vnet.ibm.com References: <20180521044220.123933-1-joel@joelfernandes.org> <20180521044220.123933-5-joel@joelfernandes.org> <20180521232537.GJ3803@linux.vnet.ibm.com> <20180522000734.GD40541@joelaf.mtv.corp.google.com> <20180522002823.GP3803@linux.vnet.ibm.com> <20180522041651.GA18405@linux.vnet.ibm.com> <20180522044327.GF40541@joelaf.mtv.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180522044327.GF40541@joelaf.mtv.corp.google.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 18052214-0012-0000-0000-00001649BCBC X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00009066; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000261; SDB=6.01036048; UDB=6.00529977; IPR=6.00815177; MB=3.00021240; MTD=3.00000008; XFM=3.00000015; UTC=2018-05-22 14:48:36 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18052214-0013-0000-0000-000052E2AD49 Message-Id: <20180522121216.GR3803@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-22_04:,, 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-1805220169 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 21, 2018 at 09:43:27PM -0700, Joel Fernandes wrote: > On Mon, May 21, 2018 at 09:16:51PM -0700, Paul E. McKenney wrote: > > On Mon, May 21, 2018 at 05:28:23PM -0700, Paul E. McKenney wrote: > > > On Mon, May 21, 2018 at 05:07:34PM -0700, Joel Fernandes wrote: > > > > On Mon, May 21, 2018 at 04:25:38PM -0700, Paul E. McKenney wrote: > > > > > On Sun, May 20, 2018 at 09:42:20PM -0700, Joel Fernandes wrote: > > > > > > We acquire gp_seq_needed locklessly. To be safe, lets do the unlocking > > > > > > after the access. > > > > > > > > > > Actually, no, we hold rnp_start's ->lock throughout. And this CPU (or in > > > > > the case of no-CBs CPUs, this task) is in charge of rdp->gp_seq_needed, > > > > > so nothing else is accessing it. Or at least that is the intent. ;-) > > > > > > > > I was talking about protecting the internal node's rnp->gp_seq_needed, not > > > > the rnp_start's gp_seq_needed. > > > > > > Ah, good point, I missed the "if" condition. This can be argued to work, > > > sort of, given that we still hold the leaf rcu_node structure's lock, > > > so that there is a limit to how far grace periods can advance. > > > > > > But the code would of course be much cleaner with your change. > > > > > > > We are protecting them in the loop: > > > > > > > > like this: > > > > for(...) > > > > if (rnp != rnp_start) > > > > raw_spin_lock_rcu_node(rnp); > > > > [...] > > > > // access rnp->gp_seq and rnp->gp_seq_needed > > > > [...] > > > > if (rnp != rnp_start) > > > > raw_spin_unlock_rcu_node(rnp); > > > > > > > > But we don't need to do such protection in unlock_out ? I'm sorry if I'm > > > > missing something, but I'm wondering if rnp->gp_seq_needed of an internal > > > > node can be accessed locklessly, then why can't that be done also in the > > > > funnel locking loop - after all we are holding the rnp_start's lock through > > > > out right? > > > > > > I was focused on the updates, and missed the rnp->gp_seq_req access in the > > > "if" statement. The current code does sort of work, but only assuming > > > that the compiler doesn't tear the load, and so your change would help. > > > Could you please resend with your other two updated patches? It depends > > > on one of the earlier patches, so does not apply cleanly as-is. I could > > > hand-apply it, but that sounds like a good way to make your updated > > > series fail to apply. ;-) > > > > > > But could you also make the commit log explicitly call out the "if" > > > condition as being the offending access? > > > > Never mind, me being stupid. I need to apply this change to the original > > commit "rcu: Make rcu_nocb_wait_gp() check if GP already requested", which > > I have done with this attribution: > > > > [ paulmck: Move lock release past "if" as suggested by Joel Fernandes. ] > > > > I have rebased my stack on top of the updated commit. > > Cool, makes sense. I am assuming this means I don't have to resend this > patch, if I do let me know :) No need. > Either way, once you push your updated tree to kernel.org, I'll double check > to make sure the change is in :) Please see 9624746baf6b ("rcu: Make rcu_nocb_wait_gp() check if GP already requested") on branch rcu/dev. Thanx, Paul