Received: by 10.192.165.148 with SMTP id m20csp5077142imm; Tue, 1 May 2018 08:41:18 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqT5dDS9HtWxRMbBRsK8aY8tmaXbNPrkLTNp8vwPpE9+PUyqMXCTrbRKKTJMO6ilzR7yMTx X-Received: by 10.98.8.69 with SMTP id c66mr4210817pfd.189.1525189278001; Tue, 01 May 2018 08:41:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525189277; cv=none; d=google.com; s=arc-20160816; b=kejnPCoqb4dUxsAAdbFOM2QA1BZYbtGJcpcVRlRScor2W2D5SbwKfbpP7rPKjFP94r N4N46Qb1ZVSc143Dr8iptdwQMrDqW8/aZHyIyyu9dsaRtTQWCKFiLM2lMXJp1Wu1EtiV 8+HieUuRz/n6fcTCskbu2KpEJKMLOehZQXq5P3XtEEQAIx7TRkvnxCsYfg6E5isjutpS hoPawYV7ToqxquC201S5+aR5uXLs8Yilm2nU4xkIMJjYKALnUIXOds4saZS/0aB3NBZo Hs4m7EtFpa0D+eoleq0PESH9CKtLKBzUqerc5Pivtu/ef6CaRKftpe4C4uxZ7OZ+k1NA 1bVg== 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=HFy155BgPcEbiUsytTlIycgMOyBtYFCxGMfrmHP+tJA=; b=tkZDTRzoiVLEVox56tJLG337ln0Y4hUgq01avzS3p5ZSK7neehGV5XJ5bjSeAFWy9m AEK+fv3rdbm6EWRgUz64ZR3b2JKmi+ZuSdxPXewf3E34OXaoL5gYox9MNNqGZ12gUwT+ ZIZSLbyWoNd05b1jgyjaDwlUAEnCUoWeyzrSTDElcUw8Dmdj2q6hJLbO/nUhSnaz68Jp KyQtsKoZar3BsU4esFr/6Y/x/+bQMOyI2hFEy0Hlm7wo4Na9vkFErXmCftybrRWtN60a F8b16jnev/unnZ5N462Yh3uRI2WXqcOR6q+nNZ1b6uI3ihpaRFAakKND+yd/6H/UgfYx I2OQ== 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 s23-v6si2668785plr.458.2018.05.01.08.41.03; Tue, 01 May 2018 08:41:17 -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 S1755397AbeEAPkx (ORCPT + 99 others); Tue, 1 May 2018 11:40:53 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:41406 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751071AbeEAPkw (ORCPT ); Tue, 1 May 2018 11:40:52 -0400 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w41Fck5d121550 for ; Tue, 1 May 2018 11:40:52 -0400 Received: from e11.ny.us.ibm.com (e11.ny.us.ibm.com [129.33.205.201]) by mx0a-001b2d01.pphosted.com with ESMTP id 2hpnts4rec-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 01 May 2018 11:40:51 -0400 Received: from localhost by e11.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 1 May 2018 11:40:50 -0400 Received: from b01cxnp22036.gho.pok.ibm.com (9.57.198.26) by e11.ny.us.ibm.com (146.89.104.198) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 1 May 2018 11:40:45 -0400 Received: from b01ledav003.gho.pok.ibm.com (b01ledav003.gho.pok.ibm.com [9.57.199.108]) by b01cxnp22036.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w41FejrR56623172; Tue, 1 May 2018 15:40:45 GMT Received: from b01ledav003.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 20250B204E; Tue, 1 May 2018 12:42:46 -0400 (EDT) Received: from paulmck-ThinkPad-W541 (unknown [9.70.82.108]) by b01ledav003.gho.pok.ibm.com (Postfix) with ESMTP id C11A9B2046; Tue, 1 May 2018 12:42:45 -0400 (EDT) Received: by paulmck-ThinkPad-W541 (Postfix, from userid 1000) id E1CA816C1940; Tue, 1 May 2018 08:42:05 -0700 (PDT) Date: Tue, 1 May 2018 08:42:05 -0700 From: "Paul E. McKenney" To: Joel Fernandes Cc: Steven Rostedt , LKML , Peter Zijlstra , Ingo Molnar , Mathieu Desnoyers , Tom Zanussi , Namhyung Kim , Thomas Gleixner , Boqun Feng , "Cc: Frederic Weisbecker" , Randy Dunlap , Masami Hiramatsu , Fenguang Wu , Baohong Liu , Vedang Patel , "Cc: Android Kernel" Subject: Re: [PATCH RFC v5 5/6] tracepoint: Make rcuidle tracepoint callers use SRCU Reply-To: paulmck@linux.vnet.ibm.com References: <20180501014204.67548-1-joelaf@google.com> <20180501014204.67548-6-joelaf@google.com> <20180501102401.2cac5781@gandalf.local.home> <20180501143601.GG26088@linux.vnet.ibm.com> <20180501152135.GJ26088@linux.vnet.ibm.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: 18050115-2213-0000-0000-0000029BEB03 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00008957; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000257; SDB=6.01025989; UDB=6.00523970; IPR=6.00805220; MB=3.00020883; MTD=3.00000008; XFM=3.00000015; UTC=2018-05-01 15:40:50 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18050115-2214-0000-0000-000059F49479 Message-Id: <20180501154205.GM26088@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-05-01_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=2 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-1805010154 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 01, 2018 at 03:23:52PM +0000, Joel Fernandes wrote: > On Tue, May 1, 2018 at 8:20 AM Paul E. McKenney > wrote: > [...] > > > > > > --- a/kernel/tracepoint.c > > > > > > +++ b/kernel/tracepoint.c > > > > > > @@ -31,6 +31,9 @@ > > > > > > extern struct tracepoint * const __start___tracepoints_ptrs[]; > > > > > > extern struct tracepoint * const __stop___tracepoints_ptrs[]; > > > > > > > > > > > > +DEFINE_SRCU(tracepoint_srcu); > > > > > > +EXPORT_SYMBOL_GPL(tracepoint_srcu); > > > > > > + > > > > > > /* Set to 1 to enable tracepoint debug output */ > > > > > > static const int tracepoint_debug; > > > > > > > > > > > > @@ -67,11 +70,16 @@ static inline void *allocate_probes(int count) > > > > > > return p == NULL ? NULL : p->probes; > > > > > > } > > > > > > > > > > > > -static void rcu_free_old_probes(struct rcu_head *head) > > > > > > +static void srcu_free_old_probes(struct rcu_head *head) > > > > > > { > > > > > > kfree(container_of(head, struct tp_probes, rcu)); > > > > > > } > > > > > > > > > > > > +static void rcu_free_old_probes(struct rcu_head *head) > > > > > > +{ > > > > > > + call_srcu(&tracepoint_srcu, head, srcu_free_old_probes); > > > > > > > > > > Hmm, is it OK to call call_srcu() from a call_rcu() callback? I > guess > > > > > it would be. > > > > > > > It is perfectly legal, and quite a bit simpler than setting something > > > > up to wait for both to complete concurrently. > > > > > > Cool. Also in this case if we call both in sequence, then I felt there > > > could be a race to free the old data since both callbacks would try to > do > > > the same thing. The same thing being freeing of the same set of old > probes > > > which would need some synchronization between the 2 callbacks. With the > > > chaining, since the ordering is assured there wouldn't be a question of > > > such a race. I could add this reasoning to the changelog as well. > > > Actually, as long as you have a solid happens-before between both of the > > callbacks and the freeing, you are in good shape. A release-acquire would > > work fine, as would a lock acquired in both callbacks and then acquired > > (and possibly released) before the free. > > Got it, thanks. For now, if its Ok with you and others, I will leave it in > the chained configuration. I also feel this is temporary since in the > future if we switch to single rcu mechanism for tracepoints (srcu), then we > could do with just a single callback. I have no problem with chained callbacks. Heck, I even test them in rcutorture. ;-) Thanx, Paul