From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933283AbdDETVy (ORCPT ); Wed, 5 Apr 2017 15:21:54 -0400 Received: from mail.kernel.org ([198.145.29.136]:48308 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752719AbdDETVq (ORCPT ); Wed, 5 Apr 2017 15:21:46 -0400 Date: Wed, 5 Apr 2017 15:21:41 -0400 From: Steven Rostedt To: "Paul E. McKenney" Cc: LKML Subject: Re: [BUG] stack tracing causes: kernel/module.c:271 module_assert_mutex_or_preempt Message-ID: <20170405152141.0e901a6b@gandalf.local.home> In-Reply-To: <20170405190810.GJ1600@linux.vnet.ibm.com> References: <20170405093207.404f8deb@gandalf.local.home> <20170405162515.GF1600@linux.vnet.ibm.com> <20170405124539.730a2365@gandalf.local.home> <20170405175925.GG1600@linux.vnet.ibm.com> <20170405145425.357937b8@gandalf.local.home> <20170405190810.GJ1600@linux.vnet.ibm.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 Wed, 5 Apr 2017 12:08:10 -0700 "Paul E. McKenney" wrote: > On Wed, Apr 05, 2017 at 02:54:25PM -0400, Steven Rostedt wrote: > > On Wed, 5 Apr 2017 10:59:25 -0700 > > "Paul E. McKenney" wrote: > > > > > > Note, this has nothing to do with trace_rcu_dyntick(). It's the > > > > function tracer tracing inside RCU, calling the stack tracer to record > > > > a new stack if it sees its larger than any stack before. All I need is > > > > a way to tell the stack tracer to not record a stack if it is in this > > > > RCU critical section. > > > > > > > > If you can add a "in_rcu_critical_section()" function, that the stack > > > > tracer can test, and simply exit out like it does if in_nmi() is set, > > > > that would work too. Below is my current work around. > > > > > > Except that the rcu_irq_enter() would already have triggered the bug > > > that was (allegedly) fixed by my earlier patch. So, yes, the check for > > > rcu_is_watching() would work around this bug, but the hope is that > > > with my earlier fix, this workaround would not be needed. > > > > Note, if I had a "in_rcu_critical_section()" I wouldn't need to call > > rcu_irq_enter(). I could fall out before that. My current workaround > > does the check, even though it breaks things, it would hopefully fix > > things as it calls rcu_irq_exit() immediately. > > OK, color me confused. What would "in_rcu_critical_section()" do? > > The rcu_is_watching() function tells you that RCU is not in an extended > quiescent state, though its return value can be iffy in the middle of > rcu_eqs_enter_common() -- which is why interrupts are disabled there. > In preemptible RCU, you can (but shouldn't) use rcu_preempt_depth() > to determine whether you are within an RCU read-side critical section, > which is what in_rcu_critical_section() sounds like to me, but I don't > see how this information would help in this situation. > > What am I missing here? > Would in_guts_of_internal_rcu_infrastructure_code() work? :-) Here's the crucial part of that stack dump again: save_stack_trace+0x1b/0x1d check_stack+0xec/0x24a stack_trace_call+0x40/0x53 0xffffffffa0026077 ? ftrace_graph_caller+0x78/0xa8 ? trace_hardirqs_off+0xd/0xf ? rcu_eqs_enter_common.constprop.71+0x5/0x108 rcu_eqs_enter_common.constprop.71+0x5/0x108 rcu_idle_enter+0x51/0x72 The stack trace was called on rcu_eqs_enter_common() inside the rcu_idle_enter() function call. Perhaps if I just let rcu disable stack tracing? Something like this: diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 50fee76..f894fc3 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -853,8 +853,10 @@ void rcu_idle_enter(void) unsigned long flags; local_irq_save(flags); + disable_stack_tracer(); rcu_eqs_enter(false); rcu_sysidle_enter(0); + enable_stack_tracer(); local_irq_restore(flags); } EXPORT_SYMBOL_GPL(rcu_idle_enter); -- Steve