Received: by 10.223.185.116 with SMTP id b49csp4077512wrg; Tue, 6 Mar 2018 09:25:41 -0800 (PST) X-Google-Smtp-Source: AG47ELv4J4GfeCgGbaYGBuOQbwX7z8RIgnC2ziE+Y4rQqVAUY+bKVIAcDFV2dLuWsLsbvGD8SGFn X-Received: by 2002:a17:902:7e87:: with SMTP id c7-v6mr17992483plm.138.1520357141756; Tue, 06 Mar 2018 09:25:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520357141; cv=none; d=google.com; s=arc-20160816; b=zhGI3SOJ4V0ldUyY1b0KQe0cxWSqTUUADhC7wwyX9vvneWmmsRYY3LKhK5hH+yC9jg qC7iwLMtaa9vygCX488n32ZQXR2J+015QBs0+i7gXe1rrTiQkGv/7WATvGQ2PbWifPHc O13Aw61qhSRUJiKF8jyOHapWZzzBd9WBrffjjnEMLBAFcbTkMg2ZIfXHqyeFYyNy+jV5 2mAKkKGc7fQzzhk4tGvoW4o3YOAksRaA160HccFl8gNOrioFGreoCOHK2ZGjH/Td6JA8 ZA/l541iCQW603xRhzMw3FN1T5cy9XGJ/R1rBzAysRtZNxN/47tAC6iRAU8Mgl8ywOAG ibyQ== 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=7u6TqaXeGj3x/OCic6a6qtUnEPqNNnGBjiO5cMiBXrI=; b=lmliznoiFa/r0uARstF6lezvnVk0ZQ4p4+9/LDBcvuIMIpc5zWBRkil9iH1C0Yubvq KhA7Q/LeUl8bHB23DupTkswQnPjrWdmYua3h4MIx4tvEi0GXuwJkLMDbO9Jk5j0wR3aj wjzPrMHc20+vlejBUkGs/+u23u7lf3AINDU0MQ2H+GgC/a8fttArdHmdQeu8dE2676M2 3zcTHfQhWoVBZ31c/r0Yl+saCRJZYEa+tyYkPFL5XqOWvS8d6zw9OfMIrU/FeAfv6dvf 9CahYcQVK3VadIBQVyfaQA63vd8ohonxHMdh9OvF21VVuGpNIu3cwL6ITI/Tcwjjz/vG lfdA== 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 59-v6si11460737plc.0.2018.03.06.09.25.26; Tue, 06 Mar 2018 09:25:41 -0800 (PST) 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 S1753992AbeCFRYK (ORCPT + 99 others); Tue, 6 Mar 2018 12:24:10 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:55312 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753979AbeCFRYI (ORCPT ); Tue, 6 Mar 2018 12:24:08 -0500 Received: from pps.filterd (m0098396.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w26HO0Do093210 for ; Tue, 6 Mar 2018 12:24:08 -0500 Received: from e16.ny.us.ibm.com (e16.ny.us.ibm.com [129.33.205.206]) by mx0a-001b2d01.pphosted.com with ESMTP id 2ghx04mafh-1 (version=TLSv1.2 cipher=AES256-SHA256 bits=256 verify=NOT) for ; Tue, 06 Mar 2018 12:24:07 -0500 Received: from localhost by e16.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 6 Mar 2018 12:24:06 -0500 Received: from b01cxnp22034.gho.pok.ibm.com (9.57.198.24) by e16.ny.us.ibm.com (146.89.104.203) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 6 Mar 2018 12:24:03 -0500 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp22034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w26HO25t51773618; Tue, 6 Mar 2018 17:24:02 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 00387B2046; Tue, 6 Mar 2018 13:26:18 -0500 (EST) Received: from paulmck-ThinkPad-W541 (unknown [9.85.196.172]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP id 6E7FDB2056; Tue, 6 Mar 2018 13:26:17 -0500 (EST) Received: by paulmck-ThinkPad-W541 (Postfix, from userid 1000) id C0B6A16C5F61; Tue, 6 Mar 2018 09:24:35 -0800 (PST) Date: Tue, 6 Mar 2018 09:24:35 -0800 From: "Paul E. McKenney" To: Byungchul Park Cc: Byungchul Park , rostedt@goodmis.org, josh@joshtriplett.org, jiangshanlai@gmail.com, kernel-team@lge.com, Mathieu Desnoyers , linux-kernel@vger.kernel.org Subject: Re: [RFC] rcu: Prevent expedite reporting within RCU read-side section Reply-To: paulmck@linux.vnet.ibm.com References: <1520314318-30916-1-git-send-email-byungchul.park@lge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 18030617-0024-0000-0000-00000332048A X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008628; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000254; SDB=6.00999276; UDB=6.00508256; IPR=6.00778594; MB=3.00019879; MTD=3.00000008; XFM=3.00000015; UTC=2018-03-06 17:24:06 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18030617-0025-0000-0000-0000473D8BC5 Message-Id: <20180306172435.GV3918@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-03-06_09:,, 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=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1803060191 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 06, 2018 at 09:43:19PM +0900, Byungchul Park wrote: > On Mar 6, 2018 2:34 PM, "Byungchul Park" wrote: > > > > Hello Paul and RCU folks, > > > > I am afraid I correctly understand and fix it. But I really wonder why > > sync_rcu_exp_handler() reports the quiescent state even in the case that > > current task is within a RCU read-side section. Do I miss something? > > Hello, > > I missed the fact that the original code is anyway safe because > the case is gonna be handled properly in rcu_read_unlock(). > > This patch just makes unnecessary spin lock/unlock within *report*() > avoided. Please ignore this if you don't think it's that worthy. I am > also not sure if it is. > > Sorry bothering you. And thanks. Not a problem, especially given that you figured it out before I got to your email. And thank you for your review of RCU! Thanx, Paul > > If I correctly understand it and you agree with it, I can add more logic > > which make it more expedited by boosting current or making it urgent > > when we fail to report the quiescent state on the IPI. > > > > ----->8----- > > From 0b0191f506c19ce331a1fdb7c2c5a00fb23fbcf2 Mon Sep 17 00:00:00 2001 > > From: Byungchul Park > > Date: Tue, 6 Mar 2018 13:54:41 +0900 > > Subject: [RFC] rcu: Prevent expedite reporting within RCU read-side section > > > > We report the quiescent state for this cpu if it's out of RCU read-side > > section at the moment IPI was just fired during the expedite process. > > > > However, current code reports the quiescent state even in the case: > > > > 1) the current task is still within a RCU read-side section > > 2) the current task has been blocked within the RCU read-side section > > > > Since we don't get to the quiescent state yet in the case, we shouldn't > > report it but check it another time. > > > > Signed-off-by: Byungchul Park > > --- > > kernel/rcu/tree_exp.h | 12 ++++++------ > > 1 file changed, 6 insertions(+), 6 deletions(-) > > > > diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h > > index 73e1d3d..cc69d14 100644 > > --- a/kernel/rcu/tree_exp.h > > +++ b/kernel/rcu/tree_exp.h > > @@ -731,13 +731,13 @@ static void sync_rcu_exp_handler(void *info) > > /* > > * We are either exiting an RCU read-side critical section (negative > > * values of t->rcu_read_lock_nesting) or are not in one at all > > - * (zero value of t->rcu_read_lock_nesting). Or we are in an RCU > > - * read-side critical section that blocked before this expedited > > - * grace period started. Either way, we can immediately report > > - * the quiescent state. > > + * (zero value of t->rcu_read_lock_nesting). We can immediately > > + * report the quiescent state. > > */ > > - rdp = this_cpu_ptr(rsp->rda); > > - rcu_report_exp_rdp(rsp, rdp, true); > > + if (t->rcu_read_lock_nesting <= 0) { > > + rdp = this_cpu_ptr(rsp->rda); > > + rcu_report_exp_rdp(rsp, rdp, true); > > + } > > } > > > > /** > > -- > > 1.9.1 > > >