From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753505AbcDYG0p (ORCPT ); Mon, 25 Apr 2016 02:26:45 -0400 Received: from bh-25.webhostbox.net ([208.91.199.152]:56178 "EHLO bh-25.webhostbox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752100AbcDYG0n (ORCPT ); Mon, 25 Apr 2016 02:26:43 -0400 Subject: Re: next: suspicious RCU usage message since commit 'rcu: Remove superfluous versions of rcu_read_lock_sched_held()' 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> <20160425054922.GA3756@linux.vnet.ibm.com> Cc: Boqun Feng , Josh Triplett , Steven Rostedt , linux-kernel@vger.kernel.org From: Guenter Roeck Message-ID: <571DB8A1.7000704@roeck-us.net> Date: Sun, 24 Apr 2016 23:26:41 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160425054922.GA3756@linux.vnet.ibm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated_sender: linux@roeck-us.net X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - bh-25.webhostbox.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roeck-us.net X-Get-Message-Sender-Via: bh-25.webhostbox.net: authenticated_id: linux@roeck-us.net X-Authenticated-Sender: bh-25.webhostbox.net: linux@roeck-us.net X-Source: X-Source-Args: X-Source-Dir: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/24/2016 10:49 PM, Paul E. McKenney wrote: > 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. > I think it would be best if you send a single patch which fixes both calls. Guenter