From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753472AbcDYFsw (ORCPT ); Mon, 25 Apr 2016 01:48:52 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]:34820 "EHLO e33.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751884AbcDYFsv (ORCPT ); Mon, 25 Apr 2016 01:48:51 -0400 X-IBM-Helo: d03dlp03.boulder.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Sun, 24 Apr 2016 22:49:22 -0700 From: "Paul E. McKenney" To: Guenter Roeck Cc: Boqun Feng , Josh Triplett , Steven Rostedt , linux-kernel@vger.kernel.org Subject: Re: next: suspicious RCU usage message since commit 'rcu: Remove superfluous versions of rcu_read_lock_sched_held()' Message-ID: <20160425054922.GA3756@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20160424211424.GA20388@roeck-us.net> <20160424213147.GW3756@linux.vnet.ibm.com> <571D5D36.3060308@roeck-us.net> <20160425052847.GY3756@linux.vnet.ibm.com> <571DAD15.6070708@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <571DAD15.6070708@roeck-us.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16042505-0009-0000-0000-000027623C6D Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Apr 24, 2016 at 10:37:25PM -0700, Guenter Roeck wrote: > On 04/24/2016 10:28 PM, Paul E. McKenney wrote: > >On Sun, Apr 24, 2016 at 04:56:38PM -0700, Guenter Roeck wrote: > >>Hi Paul, > >> > >>On 04/24/2016 02:31 PM, Paul E. McKenney wrote: > >>>On Sun, Apr 24, 2016 at 02:14:24PM -0700, Guenter Roeck wrote: > >>>>Hi, > >>>> > >>>>I see the following log message when running a qemu test for 'beagle' > >>>>with omap2plus_defconfig. > >>>> > >>>>=============================== > >>>>[ INFO: suspicious RCU usage. ] > >>>>4.6.0-rc4-next-20160422 #1 Not tainted > >>>>------------------------------- > >>>>include/trace/events/power.h:328 suspicious rcu_dereference_check() usage! > >>>> > >>>>other info that might help us debug this: > >>>> > >>>>RCU used illegally from idle CPU! > >>>>rcu_scheduler_active = 1, debug_locks = 0 > >>>>RCU used illegally from extended quiescent state! > >>>>no locks held by swapper/0/0. > >>>> > >>>>stack backtrace: > >>>>CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc4-next-20160422 #1 > >>>>Hardware name: Generic OMAP3-GP (Flattened Device Tree) > >>>>[] (unwind_backtrace) from [] (show_stack+0x10/0x14) > >>>>[] (show_stack) from [] (dump_stack+0xa8/0xe0) > >>>>[] (dump_stack) from [] (pwrdm_set_next_pwrst+0xf8/0x1cc) > >>>>[] (pwrdm_set_next_pwrst) from [] (omap3_enter_idle_bm+0x1b8/0x1e8) > >>>>[] (omap3_enter_idle_bm) from [] (cpuidle_enter_state+0x84/0x408) > >>>>[] (cpuidle_enter_state) from [] (cpu_startup_entry+0x1c8/0x3f0) > >>>>[] (cpu_startup_entry) from [] (start_kernel+0x354/0x3cc) > >>>> > >>>>bisect points to commit 'rcu: Remove superfluous versions of > >>>>rcu_read_lock_sched_held()'. Bisect log is attached. > >>> > >>>I believe that the real fix is not a revert of that commit, but rather > >>>that some of the tracing statements need an "_rcuidle" suffix. > >>> > >>>Something like the following (untested, probably does not build) patch. > >>> > >>> Thanx, Paul > >>> > >>>------------------------------------------------------------------------ > >>> > >>>commit ca91304178e1cf53ee391236a0ac3969cc814e5f > >>>Author: Paul E. McKenney > >>>Date: Sun Apr 24 14:30:16 2016 -0700 > >>> > >>> arm: Use _rcuidle tracepoint to allow use from idle > >>> > >>> Signed-off-by: Paul E. McKenney > >>> > >>>diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c > >>>index 78af6d8cf2e2..12b66b5bcc55 100644 > >>>--- a/arch/arm/mach-omap2/powerdomain.c > >>>+++ b/arch/arm/mach-omap2/powerdomain.c > >>>@@ -523,8 +523,8 @@ int pwrdm_set_next_pwrst(struct powerdomain *pwrdm, u8 pwrst) > >>> > >>> if (arch_pwrdm && arch_pwrdm->pwrdm_set_next_pwrst) { > >>> /* Trace the pwrdm desired target state */ > >>>- trace_power_domain_target(pwrdm->name, pwrst, > >>>- smp_processor_id()); > >>>+ trace_power_domain_target_rcuidle(pwrdm->name, pwrst, > >>>+ smp_processor_id()); > >>> /* Program the pwrdm desired target state */ > >>> ret = arch_pwrdm->pwrdm_set_next_pwrst(pwrdm, pwrst); > >>> } > >>> > >> > >>It does build. After applying it, I get a different traceback. > >> > >>[] (unwind_backtrace) from [] (show_stack+0x10/0x14) > >>[] (show_stack) from [] (dump_stack+0xa8/0xe0) > >>[] (dump_stack) from [] (_pwrdm_state_switch+0x188/0x32c) > >>[] (_pwrdm_state_switch) from [] (_pwrdm_post_transition_cb+0xc/0x14) > >>[] (_pwrdm_post_transition_cb) from [] (pwrdm_for_each+0x30/0x5c) > >>[] (pwrdm_for_each) from [] (pwrdm_post_transition+0x24/0x30) > >>[] (pwrdm_post_transition) from [] (omap_sram_idle+0xfc/0x240) > >>[] (omap_sram_idle) from [] (omap3_enter_idle_bm+0xf0/0x1e8) > >>[] (omap3_enter_idle_bm) from [] (cpuidle_enter_state+0x84/0x408) > >>[] (cpuidle_enter_state) from [] (cpu_startup_entry+0x1c8/0x3f0) > >>[] (cpu_startup_entry) from [] (start_kernel+0x354/0x3cc) > >> > >>After making the same change in _pwrdm_state_switch(), the traceback is gone > >>from my tests (beagle, beagle-xm, and overo-tobi). > > > >Very good! > > > >(And yes, you normally find these one at a time...) > > > Are you going to submit a formal patch ? I can, but please feel free to send mine along with yours, if you wish. Either way, please let me know. Thanx, Paul