From: Alex Shi <alex.shi@linaro.org>
To: Tony Lindgren <tony@atomide.com>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
linux-omap@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <Will.Deacon@arm.com>
Subject: Re: Regression with suspicious RCU usage splats with cpu_pm change
Date: Thu, 13 Jul 2017 17:43:06 +0800 [thread overview]
Message-ID: <c00272dc-cf84-81a2-b2e2-d52cadf7bcc6@linaro.org> (raw)
In-Reply-To: <20170713070749.GE16509@atomide.com>
On 07/13/2017 03:07 PM, Tony Lindgren wrote:
> Hi,
>
> Looks like next-20170713 gives me a bunch of "suspicious RCU usage"
> splats with cpuidle_coupled on duovero, see below. I bisected it down
> to commit 2f027e003d05 ("cpu_pm: replace raw_notifier with
> atomic_notifier").
>
> Regards,
>
> Tony
>
> 8< -----------------------
> =============================
> WARNING: suspicious RCU usage
> 4.12.0-next-20170713+ #118 Tainted: G W
> -----------------------------
> ./include/linux/rcupdate.h:611 rcu_read_lock() used illegally while idle!
> [ 2.928802]
> other info that might help us debug this:
> [ 2.928802]
> [ 2.946777]
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 2, debug_locks = 1
> RCU used illegally from extended quiescent state!
CC Catalin & Will,
It's a shame for me. :(
lockdep_rcu_suspicious() explained, rcu_read_lock can not be used after
rcu_idle_enter():
* If a CPU is in the RCU-free window in idle (ie: in the section
* between rcu_idle_enter() and rcu_idle_exit(), then RCU
* considers that CPU to be in an "extended quiescent state",
* which means that RCU will be completely ignoring that CPU.
* Therefore, rcu_read_lock() and friends have absolutely no
* effect on a CPU running in that state. In other words, even if
* such an RCU-idle CPU has called rcu_read_lock(), RCU might well
* delete data structures out from under it. RCU really has no
* choice here: we need to keep an RCU-free window in idle where
* the CPU may possibly enter into low power mode. This way we can
* notice an extended quiescent state to other CPUs that started a grace
* period. Otherwise we would delay any grace period as long as we run
* in the idle task.
Although the cpu is still alive and not going to idle yet, the RCU is
starting to count this cpu into quiescent state. I guess it's not so
good to put off rcu_idle_enter for all archs. We need another solution
on this problem, maybe unsleepable raw_rwlock? or may best way is split
the notification and the real idle trigger in the function
arm_enter_idle_state()?
Regards
Alex
next prev parent reply other threads:[~2017-07-13 9:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-13 7:07 Tony Lindgren
2017-07-13 9:43 ` Alex Shi [this message]
2017-07-13 11:50 ` Rafael J. Wysocki
2017-07-13 12:43 ` Paul E. McKenney
2017-07-16 23:24 ` Alex Shi
2017-07-17 6:08 ` Tony Lindgren
2017-07-17 12:39 ` Paul E. McKenney
2017-07-18 5:41 ` Tony Lindgren
2017-07-18 17:00 ` Paul E. McKenney
2017-07-19 8:01 ` Tony Lindgren
2017-07-27 9:55 ` Alex Shi
2017-07-27 21:32 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c00272dc-cf84-81a2-b2e2-d52cadf7bcc6@linaro.org \
--to=alex.shi@linaro.org \
--cc=Will.Deacon@arm.com \
--cc=catalin.marinas@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rafael.j.wysocki@intel.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®