From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933337AbdDETIX (ORCPT ); Wed, 5 Apr 2017 15:08:23 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:53590 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753677AbdDETIP (ORCPT ); Wed, 5 Apr 2017 15:08:15 -0400 Date: Wed, 5 Apr 2017 12:08:10 -0700 From: "Paul E. McKenney" To: Steven Rostedt Cc: LKML Subject: Re: [BUG] stack tracing causes: kernel/module.c:271 module_assert_mutex_or_preempt Reply-To: paulmck@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170405145425.357937b8@gandalf.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17040519-0008-0000-0000-000001E7237D X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006887; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000208; SDB=6.00843558; UDB=6.00415646; IPR=6.00621735; BA=6.00005271; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00014925; XFM=3.00000013; UTC=2017-04-05 19:08:12 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17040519-0009-0000-0000-0000346750E3 Message-Id: <20170405190810.GJ1600@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-05_15:,, 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-1704050161 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 I would have is: > > if (in_rcu_critical_section()) > goto out; > > rcu_irq_enter(); > > which would probably be the easiest fix. > > > > > > So could you please test my earlier patch? > > I could, but it wouldn't tell me anything immediately. It's a hard race > to hit. Which I never could hit it when I tried, but it would appear to > hit immediately when testing other things :-p > > Remember, it only triggers when a new max stack size is hit. The bug > happens when that new max stack size is in the rcu critical section. > > I guess I could force it to trigger by inserting a call in your code > that clears the max stack size. I know it is a bit of a hassle, but I would really appreciate the testing. Thanx, Paul > -- Steve > > > > > This patch does not conflict with anything on -rcu, so you could > > carry it if that helps. > > >