From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934211AbdDGPJc (ORCPT ); Fri, 7 Apr 2017 11:09:32 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:56412 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S934000AbdDGPJ0 (ORCPT ); Fri, 7 Apr 2017 11:09:26 -0400 Date: Fri, 7 Apr 2017 08:09:22 -0700 From: "Paul E. McKenney" To: Steven Rostedt Cc: linux-kernel@vger.kernel.org, Ingo Molnar , Andrew Morton Subject: Re: [PATCH 5/5 v2] rcu: Fix dyntick-idle tracing Reply-To: paulmck@linux.vnet.ibm.com References: <20170407140106.051135969@goodmis.org> <20170407140308.915512940@goodmis.org> <20170407144011.GS1600@linux.vnet.ibm.com> <20170407105316.0cda3282@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170407105316.0cda3282@gandalf.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17040715-0044-0000-0000-000002FB63A5 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006893; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000208; SDB=6.00844315; UDB=6.00416174; IPR=6.00622613; BA=6.00005275; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00014953; XFM=3.00000013; UTC=2017-04-07 15:09:23 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17040715-0045-0000-0000-000007296511 Message-Id: <20170407150922.GV1600@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-07_12:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704070126 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 07, 2017 at 10:53:16AM -0400, Steven Rostedt wrote: > On Fri, 7 Apr 2017 07:40:11 -0700 > "Paul E. McKenney" wrote: > > > On Fri, Apr 07, 2017 at 10:01:11AM -0400, Steven Rostedt wrote: > > > From: "Paul E. McKenney" > > > > > > The tracing subsystem started using rcu_irq_entry() and rcu_irq_exit() > > > (with my blessing) to allow the current _rcuidle alternative tracepoint > > > name to be dispensed with while still maintaining good performance. > > > Unfortunately, this causes RCU's dyntick-idle entry code's tracing to > > > appear to RCU like an interrupt that occurs where RCU is not designed > > > to handle interrupts. > > > > > > This commit fixes this problem by moving the zeroing of ->dynticks_nesting > > > after the offending trace_rcu_dyntick() statement, which narrows the > > > window of vulnerability to a pair of adjacent statements that are now > > > marked with comments to that effect. > > > > > > Link: http://lkml.kernel.org/r/20170405193928.GM1600@linux.vnet.ibm.com > > > > > > Reported-by: Steven Rostedt > > > Signed-off-by: Paul E. McKenney > > > Signed-off-by: Steven Rostedt (VMware) > > > --- > > > kernel/rcu/tree.c | 48 +++++++++++++++++++++++------------------------- > > > 1 file changed, 23 insertions(+), 25 deletions(-) > > > > > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > > > index 50fee7689e71..8b4d273331e4 100644 > > > --- a/kernel/rcu/tree.c > > > +++ b/kernel/rcu/tree.c > > > @@ -57,6 +57,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > > > > #include "tree.h" > > > #include "rcu.h" > > > @@ -771,25 +772,24 @@ cpu_needs_another_gp(struct rcu_state *rsp, struct rcu_data *rdp) > > > } > > > > > > /* > > > - * rcu_eqs_enter_common - current CPU is moving towards extended quiescent state > > > + * rcu_eqs_enter_common - current CPU is entering an extended quiescent state > > > * > > > - * If the new value of the ->dynticks_nesting counter now is zero, > > > - * we really have entered idle, and must do the appropriate accounting. > > > - * The caller must have disabled interrupts. > > > + * Enter idle, doing appropriate accounting. The caller must have > > > + * disabled interrupts. > > > */ > > > -static void rcu_eqs_enter_common(long long oldval, bool user) > > > +static void rcu_eqs_enter_common(bool user) > > > { > > > struct rcu_state *rsp; > > > struct rcu_data *rdp; > > > - RCU_TRACE(struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);) > > > + struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks); > > > > > > - trace_rcu_dyntick(TPS("Start"), oldval, rdtp->dynticks_nesting); > > > + trace_rcu_dyntick(TPS("Start"), rdtp->dynticks_nesting, 0); > > > if (IS_ENABLED(CONFIG_RCU_EQS_DEBUG) && > > > !user && !is_idle_task(current)) { > > > struct task_struct *idle __maybe_unused = > > > idle_task(smp_processor_id()); > > > > > > - trace_rcu_dyntick(TPS("Error on entry: not idle task"), oldval, 0); > > > + trace_rcu_dyntick(TPS("Error on entry: not idle task"), rdtp->dynticks_nesting, 0); > > > rcu_ftrace_dump(DUMP_ORIG); > > > WARN_ONCE(1, "Current pid: %d comm: %s / Idle pid: %d comm: %s", > > > current->pid, current->comm, > > > @@ -800,7 +800,10 @@ static void rcu_eqs_enter_common(long long oldval, bool user) > > > do_nocb_deferred_wakeup(rdp); > > > } > > > rcu_prepare_for_idle(); > > > - rcu_dynticks_eqs_enter(); > > > + stack_tracer_disable(); > > > + rdtp->dynticks_nesting = 0; /* Breaks tracing momentarily. */ > > > + rcu_dynticks_eqs_enter(); /* After this, tracing works again. */ > > > + stack_tracer_enable(); > > > > Hmmm... There is not supposed to be any tracing in this interval, > > Why not? function tracing happens without an issue. But then again, > function tracing doesn't depend on RCU. > > > and interrupts are disabled. Wouldn't it be better to have something > > that made tracing illegal during this interval? > > I don't see an issue here. Function tracing is fine. There should be no > trace_events() as those are static events and shouldn't dynamically > appear in this interval. > > The problem I hit is that stack tracing uses function tracing to check > the stack of all functions. It doesn't need RCU either, unless it hits > a new "max stack", which it then calls save_stack_trace(), which does a > lot, and it does perform an rcu_read_lock(), which is what broke. > > I'm fine with tracing, as that works. What doesn't work is tracing a > new max stack. > > > > > Yeah, I am a bit concerned about idle-entry latency... > > > > Which should now be fine because of the inlined this_cpu_inc/dec() > which is very efficient and made for fast paths like this. OK, I am willing to let people complain if they can measure the difference. If they can measure the difference, there are some things we can do. Thanx, Paul