Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1509835pxk; Mon, 31 Aug 2020 23:48:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw1Cw9J58KSZ7znaBvfufBObRy1ztyL677VFacRFyZl0a3EDIj7OCytRL0faJo3xBblEdyQ X-Received: by 2002:a17:906:680a:: with SMTP id k10mr222437ejr.82.1598942936597; Mon, 31 Aug 2020 23:48:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598942936; cv=none; d=google.com; s=arc-20160816; b=bYE3I7ArhYSXIyCMwVx3bnyc1GjC68Wf+VawRi/cBeWIIzZygCtIo3uixS7nWBd5QS oa2oHbHSlNdaeAoMKLJhgZm15JMAAKrpDbGn6kCrMG/KvFmBKBU1gTD8qmtfCqMAwZve I3j5Mp3pmw7gfNvozeg/PhtpDNWvE1Xk8SS6SydJTMO6Q+1HUpAYLPF0dFxnkoW/dNao ZdL1eqitRleR67gVVhATg+4xIZCJdN1HAoDhMXyHb1IMNqsnpXIzK3ue8JYpJUCGPIVJ 5x+4HRrjVYQYct1LPYktR0Dj5t/8JER57F0xn1JMedF5aAEo4smiVf8h/j7WerIIo5jM OnwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=oifFdmXULzK6sVZQwlchaA3hM9sOOMssvlLwC1vno/Y=; b=zMm+Zw4AjpbhSjVV1FlT7sJHlooYt7a3YboD1hL3p8Ywq/khzXj55fWD152WGreq+Y Lnf1xtkrOWN0/UoLwesNaWM+Ae3HFDUs8K9eWNxq0dSCfs4LyBynglVl6cbX/XKuhS4w T1ygByvfDMzzaLwa7yjedgufSYmf8bOorUAX/CBeHvsRg5bKs3RZijRC8MNuxOzIdYsN rxK7rUHtqTNYJ0j6wQR7ykivQB5AdRpXO3vWKGF5uMHu0qzyoXqbFJD38UNjPEgjqNnG 3D135s5gttsLkkkqnc4zBSpy4dx11gNcLcLCff6qowRSdRQYUDZUq8/6BwLmaTXEMIdO 6wDA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=EDF7LoOd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dn20si229093ejc.377.2020.08.31.23.48.33; Mon, 31 Aug 2020 23:48:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=EDF7LoOd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726594AbgIAGrd (ORCPT + 99 others); Tue, 1 Sep 2020 02:47:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58152 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726012AbgIAGrb (ORCPT ); Tue, 1 Sep 2020 02:47:31 -0400 Received: from mail-vk1-xa44.google.com (mail-vk1-xa44.google.com [IPv6:2607:f8b0:4864:20::a44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 56B0EC0612AC for ; Mon, 31 Aug 2020 23:47:31 -0700 (PDT) Received: by mail-vk1-xa44.google.com with SMTP id h23so83480vkn.4 for ; Mon, 31 Aug 2020 23:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oifFdmXULzK6sVZQwlchaA3hM9sOOMssvlLwC1vno/Y=; b=EDF7LoOdrSEdX5GMv9D+fIHt9SNaw7sL3J6OZhS+t0Ap7gtIF9JH2gsgMz2uECU3IG CgM21YqTGpH9DBZViZWoE6ybiuuOOL6N+CWNuDp7hofQ9nlZCJt1Q+vTkRmZJRg42029 rrbvG9HRw+7hZqrbOwK6OIJhlxojzK5uvYqxkZLhkgCaliaIrF7g++Z8Hws2NbReBvcY MmlGw2VzDX3Pg9oXixYwsHeLg1jCKFH4hQQFaa6STpYEioJGHp3/oakcIvls3yfiXsKW wYHlcHBJMomA/4axUYBF7DMbaFXGP7grNlkl8A2Dxgbdff0V62gGPdwk8Kxva6VEZ8P7 QQig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oifFdmXULzK6sVZQwlchaA3hM9sOOMssvlLwC1vno/Y=; b=QSaresZ9ddRAzgfcUt6FLEnC9aqqvYP1xf0LMyKsMbqJpLaBuNjHKf7RoLeGhK4qQL RV/I0Dg8MDdfK/xeepfgYm7lv3RvyetjNDmU78mTjszW8sEvSgqSbEan/Y4en98Kv5Lg OjNuPCw/wUoP9rImCqWl+SNgjU7vMV15+AX+je0scrBP1/LVu8XVEwGjLVY89RNnBhLH YkvsltNw2JX5DLhxkVt8W9D6mFZw4upmnT1h2Mx8T1GIh13sUBcr58KNGmL3uTA30HBn luWTaK8zcSmMV/Gk5MmLhT73U8FT4bmqS92jk+te3lrR2Z+cvcp+e3P8YZlrxvFMeoYj pHOA== X-Gm-Message-State: AOAM530zWgGkGoazOV1AC6gnW1tFTaaS6XE/bMOEjnebn2ZWTjeZIrco Q+TPHgjKmU7TLmIoDDfh108t7ZOYTKQKJR4u1q2paA== X-Received: by 2002:a1f:a286:: with SMTP id l128mr250532vke.1.1598942850433; Mon, 31 Aug 2020 23:47:30 -0700 (PDT) MIME-Version: 1.0 References: <20200831194402.GD2855@paulmck-ThinkPad-P72> In-Reply-To: <20200831194402.GD2855@paulmck-ThinkPad-P72> From: Ulf Hansson Date: Tue, 1 Sep 2020 08:46:54 +0200 Message-ID: Subject: Re: WARNING: suspicious RCU usage - sdhci-pltfm: SDHCI platform and OF driver helper To: paulmck@kernel.org, "Rafael J. Wysocki" , Saravana Kannan Cc: Naresh Kamboju , open list , linux-mmc , lkft-triage@lists.linaro.org, rcu@vger.kernel.org, Linux PM , Anders Roxell , Arnd Bergmann , Rajendra Nayak , John Stultz , Stephen Boyd , Lars Povlsen , madhuparnabhowmik10@gmail.com, Viresh Kumar , Vincent Guittot , peterz@infrdead.org, Lina Iyer Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org + Saravanna, Rafael, Lina On Mon, 31 Aug 2020 at 21:44, Paul E. McKenney wrote: > > On Mon, Aug 31, 2020 at 12:02:31PM +0530, Naresh Kamboju wrote: > > While booting linux mainline kernel on arm64 db410c this kernel warning > > noticed. > > > > metadata: > > git branch: master > > git repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > git commit: f75aef392f869018f78cfedf3c320a6b3fcfda6b > > git describe: v5.9-rc3 > > make_kernelversion: 5.9.0-rc3 > > kernel-config: > > http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/dragonboard-410c/lkft/linux-mainline/2965/config > > > > Boot log, > > > > [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd030] > > [ 0.000000] Linux version 5.9.0-rc3 (oe-user@oe-host) > > (aarch64-linaro-linux-gcc (GCC) 7.3.0, GNU ld (GNU Binutils) > > 2.30.0.20180208) #1 SMP PREEMPT Mon Aug 31 00:23:15 UTC 2020 > > [ 0.000000] Machine model: Qualcomm Technologies, Inc. APQ 8016 SBC > > <> > > [ 5.299090] sdhci: Secure Digital Host Controller Interface driver > > [ 5.299140] sdhci: Copyright(c) Pierre Ossman > > [ 5.304313] > > [ 5.307771] Synopsys Designware Multimedia Card Interface Driver > > [ 5.308588] ============================= > > [ 5.308593] WARNING: suspicious RCU usage > > [ 5.316628] sdhci-pltfm: SDHCI platform and OF driver helper > > [ 5.320052] 5.9.0-rc3 #1 Not tainted > > [ 5.320057] ----------------------------- > > [ 5.320063] /usr/src/kernel/include/trace/events/lock.h:37 > > suspicious rcu_dereference_check() usage! > > [ 5.320068] > > [ 5.320068] other info that might help us debug this: > > [ 5.320068] > > [ 5.320074] > > [ 5.320074] rcu_scheduler_active = 2, debug_locks = 1 > > [ 5.320078] RCU used illegally from extended quiescent state! > > [ 5.320084] no locks held by swapper/0/0. > > [ 5.320089] > > [ 5.320089] stack backtrace: > > [ 5.320098] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.9.0-rc3 #1 > > [ 5.346354] sdhci_msm 7864900.sdhci: Got CD GPIO > > [ 5.346446] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) > > [ 5.346452] Call trace: > > [ 5.346463] dump_backtrace+0x0/0x1f8 > > [ 5.346471] show_stack+0x2c/0x38 > > [ 5.346480] dump_stack+0xec/0x15c > > [ 5.346490] lockdep_rcu_suspicious+0xd4/0xf8 > > [ 5.346499] lock_acquire+0x3d0/0x440 > > [ 5.346510] _raw_spin_lock_irqsave+0x80/0xb0 > > [ 5.413118] __pm_runtime_suspend+0x34/0x1d0 > > [ 5.417457] psci_enter_domain_idle_state+0x4c/0xb0 > > [ 5.421795] cpuidle_enter_state+0xc8/0x610 > > [ 5.426392] cpuidle_enter+0x3c/0x50 > > [ 5.430561] call_cpuidle+0x44/0x80 > > [ 5.434378] do_idle+0x240/0x2a0 > > RCU ignores CPUs in the idle loop, which means that you cannot use > rcu_read_lock() from the idle loop without use of something like > RCU_NONIDLE(). If this is due to event tracing, you should use the > _rcuidle() variant of the event trace statement. In the runtime suspend path, the runtime PM core calls device_links_read_lock() - if the device in question has any links to suppliers (to allow them to be suspended too). device_links_read_lock() calls srcu_read_lock(). It turns out that the device in question (the CPU device that is attached to genpd) didn't have any links before - but that seems to have changed, due to the work done by Saravana (links become created on a per resource basis, parsed from DT during boot). > > Note also that Peter Zijlstra (CCed) is working to shrink the portion > of the idle loop that RCU ignores. Not sure that it covers your > case, but it is worth checking. Thanks for letting me know. Let's see what Peter thinks about this then. Apologize for my ignorance, but from a cpuidle point of view, what does it mean using RCU_NONIDLE()? I guess we should avoid RCU_NONIDLE on bigger code paths? I could add RCU_NONIDLE for the calls to pm_runtime_put_sync_suspend() and pm_runtime_get_sync() in psci_enter_domain_idle_state(). Perhaps that's the easiest approach, at least to start with. Or do you have any other ideas? [...] Kind regards Uffe