From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934569AbdDGR01 (ORCPT ); Fri, 7 Apr 2017 13:26:27 -0400 Received: from mail.kernel.org ([198.145.29.136]:43352 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934507AbdDGR0S (ORCPT ); Fri, 7 Apr 2017 13:26:18 -0400 Date: Fri, 7 Apr 2017 13:26:13 -0400 From: Steven Rostedt To: Mathieu Desnoyers Cc: linux-kernel , Ingo Molnar , Andrew Morton , "Paul E. McKenney" Subject: Re: [PATCH 7/5] tracing: Make sure rcu_irq_enter() can work for trace_*_rcuidle() trace events Message-ID: <20170407132613.4a9fa430@gandalf.local.home> In-Reply-To: <1475342880.4473.1491585545139.JavaMail.zimbra@efficios.com> References: <20170407140106.051135969@goodmis.org> <20170407130615.2309b96d@gandalf.local.home> <1475342880.4473.1491585545139.JavaMail.zimbra@efficios.com> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 7 Apr 2017 17:19:05 +0000 (UTC) Mathieu Desnoyers wrote: > ----- On Apr 7, 2017, at 1:06 PM, rostedt rostedt@goodmis.org wrote: > > > From: "Steven Rostedt (VMware)" > > > > Stack tracing discovered that there's a small location inside the RCU > > infrastructure that calling rcu_irq_enter() does not work. As trace events > > that -> where ok > > Do you have a link to the lkml thread where this stack tracing discovery > happened ? Actually it's this thread. But here: Version 1 of the patch series: http://lkml.kernel.org/r/20170406164237.874767449@goodmis.org Version 2 of the patch series: http://lkml.kernel.org/r/20170407140106.051135969@goodmis.org > > > use rcu_irq_enter() it must make sure that it is functionable. A check > > I don't think functionable is the word you are looking for here. Perhaps > "must make sure that it can be invoked" ? > > > against rcu_irq_enter_disabled() is added with a WARN_ON_ONCE() as no trace > > event should ever be used in that part of RCU. If the warning is triggered, > > then the trace event is ignored. > > > > Cc: Mathieu Desnoyers > > Signed-off-by: Steven Rostedt (VMware) > > --- > > include/linux/tracepoint.h | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h > > index f72fcfe..8baef96 100644 > > --- a/include/linux/tracepoint.h > > +++ b/include/linux/tracepoint.h > > @@ -159,6 +159,8 @@ extern void syscall_unregfunc(void); > > TP_PROTO(data_proto), \ > > TP_ARGS(data_args), \ > > TP_CONDITION(cond), \ > > + if (WARN_ON_ONCE(rcu_irq_enter_disabled())) \ > > + return; \ > > I must admit that it's a bit odd to have: > > if (WARN_ON_ONCE(rcu_irq_enter_disabled())) > return; > rcu_irq_enter_irqson() Welcome to MACRO MAGIC! > > as one argument to the __DO_TRACE() macro. To me it's a bit unexpected > coding-style wise. Am I the only one not comfortable with the proposed > syntax ? The entire TRACE_EVENT()/__DO_TRACE() is special. I thought about add yet another parameter, but as it doesn't change much, I figured this was good enough. We could beak it up if you like: #define RCU_IRQ_ENTER_CHECK \ if (WARN_ON_ONCE(rcu_irq_enter_disabled()) \ return; \ rcu_irq_enter_irqson(); [..] __DO_TRACE(&__tracepoint_##name, \ TP_PROTO(data_proto), \ TP_ARGS(data_args), \ TP_CONDITION(cond), \ PARAMS(RCU_IRQ_ENTER_CHECK), \ rcu_irq_exit_irqson()); \ Would that make you feel more comfortable? -- Steve