Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1207818imm; Wed, 11 Jul 2018 20:10:20 -0700 (PDT) X-Google-Smtp-Source: AAOMgpd0+0g2oBR1usBtB1iNlQJu10iUcmFBCJCpXbvLTJVUv5ajQqnfhfU85tmfrbmxPQVIBdTB X-Received: by 2002:a62:3687:: with SMTP id d129-v6mr492313pfa.137.1531365020780; Wed, 11 Jul 2018 20:10:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531365020; cv=none; d=google.com; s=arc-20160816; b=vhgvi/Z/zbYVjmTmSUUeyyWx2d5XkpRddNJU+449DzGiNtYnhX+Vsn8JMpHu/t4RIZ XeIaNMl+lCINGv+4XwmTjkECov0xpQ49yvyn9dDk0M7HSrrl2auZVQqFUi+Hcue2yo0H XLMsB0+LZVIkuRIB0QeSIb1xK27lDISPm+SwF3ttb0MBPIhntvUMnYmOBZA+UKTvA3cP u3/gwuz0FjR5UqQtJ4dCGX1DCVgaWqoElPphSkHghZu+7RO41eGZDpCoo9KmRZRY7xVS 5zNFKTUusHD8JzRodcI0E338wPBbFV1eBp9zZHPM3fhOnaI+oQoAxLNZmuqcrrl7kkUM EAsQ== 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=DSu97wBZ35LKfB/W04R4pCM+XRqTmlt5gdTFIvIMGjc=; b=AJid2g4Z4PBW3xqFbiLuRRT2hGdOqKz9gM8WSByOJBhsw0JfH4hYuL+5Kh0gks0zQY a5DJRLvpYPMr3KRLz6sK7Q7SvNHc5kWAVsk2JmG+ziowMtvhOD2fRC5bh+38QL3jekOx IlyrmDsRKe7iCXprpe5/A7Q3OuQdNOVpLsrc159N5sXk7LKBgRIep1APW6WyWMWgwDJ3 MX5pMsS/SXyCsqC7aj4oUmURGIJcM62iPsZdLBUGm64lsb8oarrITnYMgxST0OeIe2Q/ G7jPnmDYSHGzAh2TgSB9vxBBo+PZ+DL7+syqNT/VCY6ORWiEFY9cDnn3E3AGZRuPbTjl c9Zw== 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 w10-v6si11790326pfk.162.2018.07.11.20.10.05; Wed, 11 Jul 2018 20:10:20 -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 S2403814AbeGLB3l (ORCPT + 99 others); Wed, 11 Jul 2018 21:29:41 -0400 Received: from mail.kernel.org ([198.145.29.99]:54256 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726701AbeGLB3l (ORCPT ); Wed, 11 Jul 2018 21:29:41 -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 EDE7620BEC; Thu, 12 Jul 2018 01:22:38 +0000 (UTC) Date: Wed, 11 Jul 2018 21:22:37 -0400 From: Steven Rostedt To: Joel Fernandes Cc: "Paul E. McKenney" , 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 , Thomas Glexiner , Tom Zanussi Subject: Re: [PATCH v9 4/7] tracepoint: Make rcuidle tracepoint callers use SRCU Message-ID: <20180711212237.3eff418f@vmware.local.home> In-Reply-To: <20180711205639.GB32091@joelaf.mtv.corp.google.com> References: <20180628182149.226164-1-joel@joelfernandes.org> <20180628182149.226164-5-joel@joelfernandes.org> <20180711124954.GE2476@hirez.programming.kicks-ass.net> <20180711090003.42596c2b@gandalf.local.home> <20180711142744.GN3593@linux.vnet.ibm.com> <20180711104618.05dc4b46@gandalf.local.home> <20180711151559.GR3593@linux.vnet.ibm.com> <20180711205639.GB32091@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 13:56:39 -0700 Joel Fernandes wrote: > > > #define __DECLARE_TRACE(name, proto, args, cond, data_proto, data_args) \ > > > extern struct tracepoint __tracepoint_##name; \ > > > static inline void trace_##name(proto) \ > > > { \ > > > if (static_key_false(&__tracepoint_##name.key)) \ > > > __DO_TRACE(&__tracepoint_##name, \ > > > TP_PROTO(data_proto), \ > > > TP_ARGS(data_args), \ > > > TP_CONDITION(cond), 0); \ > > > if (IS_ENABLED(CONFIG_LOCKDEP) && (cond)) { \ > > > rcu_read_lock_sched_notrace(); \ > > > rcu_dereference_sched(__tracepoint_##name.funcs);\ > > > rcu_read_unlock_sched_notrace(); \ > > > } \ > > > } > > > > > > Because lockdep would only trigger warnings when the tracepoint was > > > enabled and used in a place it shouldn't be, we added the above > > > IS_ENABLED(CONFIG_LOCKDEP) part to test regardless if the the > > > tracepoint was enabled or not. Because we do this, we don't need to > > > have the test in the __DO_TRACE() code itself. That means we can clean > > > up the code as per Peter's suggestion. > > > > Indeed, the rcu_dereference_sched() would catch it in that case, so > > agreed, Peter's suggestion isn't losing any debuggability. > > Hmm, but if we are doing the check later anyway, then why not do it in > __DO_TRACE itself? Because __DO_TRACE is only called if the trace event is enabled. If we never enable a trace event, we never know if it has a potential of doing it wrong. The second part is to trigger the warning immediately regardless if the trace event is enabled or not. > > Also I guess we are discussing about changing the rcu_dereference_sched which > I think should go into a separate patch since my patch isn't touching how the > rcuidle==0 paths use the RCU API. So I think this is an existing issue > independent of this series. But the code you added made it much more complex to keep the checks as is. If we remove the checks then this patch doesn't need to have all the if statements, and we can do it the way Peter suggested. But sure, go ahead and make a separate patch first that removes the checks from __DO_TRACE() first if you want to. -- Steve