Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp497293imm; Wed, 11 Jul 2018 06:15:25 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdtr7kLHDXpMqUvvVokyUPcYEYOrhDYuiI9iMNgPdY9Qe+9BPhJbQXO71imAsU9WLrd/fkh X-Received: by 2002:a62:990f:: with SMTP id d15-v6mr30016492pfe.162.1531314925882; Wed, 11 Jul 2018 06:15:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531314925; cv=none; d=google.com; s=arc-20160816; b=RmzEzGJiAPfsBeogJO/1JbQ3pfwj8wsQ1svpT7zAbE+ase0OYm82AUwFARrqnSKyC4 089zVmxM//GA0/A8wX2e63BIkrDKP/pSbGeCHyC+84kmg56yPF36RcoIAKLZbkDr6W3l jCdiD3olRU5/TksOf8Zo295lVhp7tqQAk/I7FF16Tyq438iDj/XF03QXbG8xD1svlre/ 5N/tp8M0F1f5MQrU9s5rxpJsDJZeczgB/V3XpWXPLJiEaCZuOtmuU8AgoBte/viK2zzu 13OVZHoeW1tnnkARnbZ3auDpYGAE9Qtfg8Ay5GTK8aMVY+ROpTHObR/O0erX5zktgpt6 AhDw== 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=5zcmnHfXMiLIIuJR8h4Q2SBlFsu6yn8sC3GgLBcxGkw=; b=kvs4q3Jj0ZCI/H0LoL6nfvvedq8VdefGuYUcUxleKKu0JXl/seXy+1NC//JNWtWKBu xkJcypqtrsMmACnYJ1WkZCipi1jTMgIcfQxjltePCRAN7+fCVAD6RjgwTmoRgzrkp4vZ 39YPZdhyYkcenMoYFaSTncK1fP0FwBOU1kcFv7ljbixpLZ5EAAehao4QKAt0UARLDiih DyPz8atacBd7LMvopC2OtvyAg8bGKUdkQZHh4JlVnIl9EeA0VNH8grJwe7FrdjXQQnjt P59ABniWT+z4IYlU7wUl3LqCNUNx3xEG5LyN2Qg0DqXp/RYgt0MRaiwMbHkma1+flFjN HrCg== 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 l12-v6si18927198plc.215.2018.07.11.06.15.10; Wed, 11 Jul 2018 06:15:25 -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 S2387759AbeGKNLI (ORCPT + 99 others); Wed, 11 Jul 2018 09:11:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:45140 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732420AbeGKNLI (ORCPT ); Wed, 11 Jul 2018 09:11:08 -0400 Received: from gandalf.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 D78082089B; Wed, 11 Jul 2018 13:06:50 +0000 (UTC) Date: Wed, 11 Jul 2018 09:06:49 -0400 From: Steven Rostedt To: Peter Zijlstra Cc: Joel Fernandes , 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: <20180711090649.68af40f9@gandalf.local.home> In-Reply-To: <20180711125647.GG2476@hirez.programming.kicks-ass.net> References: <20180628182149.226164-1-joel@joelfernandes.org> <20180628182149.226164-5-joel@joelfernandes.org> <20180711125647.GG2476@hirez.programming.kicks-ass.net> X-Mailer: Claws Mail 3.16.0 (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 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. > > Also, does the above want to be barrier instead of synchronize, so as to > guarantee completion of the callbacks. Not sure what you mean here. -- Steve > > > +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); > > +} > > + > > static inline void release_probes(struct tracepoint_func *old) > > { > > if (old) { > > struct tp_probes *tp_probes = container_of(old, > > struct tp_probes, probes[0]); > > + /* > > + * Tracepoint probes are protected by both sched RCU and SRCU, > > + * by calling the SRCU callback in the sched RCU callback we > > + * cover both cases. So let us chain the SRCU and sched RCU > > + * callbacks to wait for both grace periods. > > + */ > > call_rcu_sched(&tp_probes->rcu, rcu_free_old_probes); > > } > > }