Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1208384imm; Wed, 11 Jul 2018 20:11:17 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdNPPvHjUM+Vz00JNbw9JMt/sbAp3IT12NJgQRfcuYlOpH7+KcXLokw0tk2m5jzNOGVyAo+ X-Received: by 2002:a63:951e:: with SMTP id p30-v6mr464400pgd.318.1531365077015; Wed, 11 Jul 2018 20:11:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531365076; cv=none; d=google.com; s=arc-20160816; b=nEbFES6kNZyyi1+BRbXPJgLaZVZ2rsP3RJFKvSOH/MzQ/AUGxvA3bokFEgaom8bImU ORePc48ob9QVJFaYKFLcHAyF83NIQAwiG0A+bp0y6qnwY7OlhqO80q9HcsCdF7dNmrxC mMeHji/zOangCDYAsKH6vZMWNsa6ekNpg2Wpt3T1/szPfJGYuJ2S8qlJ/ANFYIgrMvNR d7U2aroY81b5XIn1Es7O4taWNdgu60sQYJSrSSjR27BF7lHFJKN8eYjecgZ+ib5ybIKz YtPnrbM7A80/haIakL86Bi9ADMVBYiE/gYqGKoVqV+hRj1WMJrUr282zWUlv/EEaj+Cn X0kA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=Hv8YwcAIvyg09i4EQn37Tj3JAKxLs8u03Oqpy9ZDa7w=; b=rKM51HfHNsvr/MGiV/NTmqMGxHTOtira296nzmduN8lBNjTQtEBMeFjkKHmRE65M5X awFoyaL28euJTRoiTNDfivQmI6y3CQcXCEY7D0r1abLq5nnZLPF2JWMEd6SmnM5Rov0t aQQOSu97fu0BiTJruwa4XYGlZ5bmERbnL9/7LAL/irn4K/YOWz8g5KcRENNPWdfxU8BL kWUHfL9MrZ0ffW/v8x3F0sVRLHqPkNsPLWeBUS0iA3noMQSmfQ8QX6gl8S1zuAI349of YZSiXpcQmCKTqo15dg53yeiE3ICcxWhkGwD3N7oMVXEwPuxqqiqCxZd7RE5tk8gJV7TE Rn3w== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w3-v6si18870449pll.96.2018.07.11.20.11.02; Wed, 11 Jul 2018 20:11:16 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2403875AbeGLBdc (ORCPT + 99 others); Wed, 11 Jul 2018 21:33:32 -0400 Received: from mail.kernel.org ([198.145.29.99]:58684 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2403839AbeGLBdc (ORCPT ); Wed, 11 Jul 2018 21:33:32 -0400 Received: from vmware.local.home (cpe-66-24-56-78.stny.res.rr.com [66.24.56.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A51472146F; Thu, 12 Jul 2018 01:26:28 +0000 (UTC) Date: Wed, 11 Jul 2018 21:26:26 -0400 From: Steven Rostedt To: Joel Fernandes Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, Boqun Feng , Byungchul Park , Ingo Molnar , Julia Cartwright , linux-kselftest@vger.kernel.org, Masami Hiramatsu , Mathieu Desnoyers , Namhyung Kim , Paul McKenney , Thomas Glexiner , Tom Zanussi Subject: Re: [PATCH v9 4/7] tracepoint: Make rcuidle tracepoint callers use SRCU Message-ID: <20180711212626.5992e2c8@vmware.local.home> In-Reply-To: <20180712003100.GC32091@joelaf.mtv.corp.google.com> References: <20180628182149.226164-1-joel@joelfernandes.org> <20180628182149.226164-5-joel@joelfernandes.org> <20180711125647.GG2476@hirez.programming.kicks-ass.net> <20180711090649.68af40f9@gandalf.local.home> <20180712003100.GC32091@joelaf.mtv.corp.google.com> X-Mailer: Claws Mail 3.15.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 11 Jul 2018 17:31:00 -0700 Joel Fernandes wrote: > On Wed, Jul 11, 2018 at 09:06:49AM -0400, Steven Rostedt wrote: > > On Wed, 11 Jul 2018 14:56:47 +0200 > > Peter Zijlstra wrote: > > > > > On Thu, Jun 28, 2018 at 11:21:46AM -0700, Joel Fernandes wrote: > > > > static inline void tracepoint_synchronize_unregister(void) > > > > { > > > > + synchronize_srcu(&tracepoint_srcu); > > > > synchronize_sched(); > > > > } > > > > > > Given you below do call_rcu_sched() and then call_srcu(), isn't the > > > above the wrong way around? > > > > Good catch! > > > > release_probes() > > call_rcu_sched() > > ---> rcu_free_old_probes() queued > > > > tracepoint_synchronize_unregister() > > synchronize_srcu(&tracepoint_srcu); > > < finishes right away > > > synchronize_sched() > > --> rcu_free_old_probes() > > --> srcu_free_old_probes() queued > > > > Here tracepoint_synchronize_unregister() returned before the srcu > > portion ran. > > But isn't the point of synchronize_rcu to make sure that we're no longer in > an RCU read-side section, not that *all* queued callbacks already ran? So in that > case, I think it doesn't matter which order the 2 synchronize functions are > called in. Please let me know if if I missed something! > > I believe what we're trying to guarantee here is that no tracepoints using > either flavor of RCU are active after tracepoint_synchronize_unregister > returns. Yes you are correct. If tracepoint_synchronize_unregister() is only to make sure that there is no more trace events using the probes, then this should work. I was focused on looking at it with release_probes() too. So the patch is fine as is. -- Steve