From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org,
"Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
Andi Kleen <ak@linux.intel.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
linux-pm@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] cpufreq: Fix RCU reboot regression on x86 PIC machines
Date: Thu, 03 Oct 2019 17:05:28 +0200 [thread overview]
Message-ID: <2393023.mJgu6cDs6C@kreacher> (raw)
In-Reply-To: <20191003140828.14801-1-ville.syrjala@linux.intel.com>
On Thursday, October 3, 2019 4:08:28 PM CEST Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Since 4.20-rc1 my PIC machines no longer reboot/shutdown.
> I bisected this down to commit 45975c7d21a1 ("rcu: Define RCU-sched
> API in terms of RCU for Tree RCU PREEMPT builds").
>
> I traced the hang into
> -> cpufreq_suspend()
> -> cpufreq_stop_governor()
> -> cpufreq_dbs_governor_stop()
> -> gov_clear_update_util()
> -> synchronize_sched()
> -> synchronize_rcu()
>
> Only PREEMPT=y is affected for obvious reasons. The problem
> is limited to PIC machines since they mask off interrupts
> in i8259A_shutdown() (syscore_ops.shutdown() registered
> from device_initcall()).
Let me treat this as a fresh bug report. :-)
> I reported this long ago but no better fix has surfaced,
So I don't recall seeing the original report or if I did, I had not understood
the problem then.
> hence sending out my initial workaround which I've been
> carrying around ever since. I just move cpufreq_core_init()
> to late_initcall() so the syscore_ops get registered in the
> oppsite order and thus the .shutdown() hooks get executed
> in the opposite order as well. Not 100% convinced this is
> safe (especially moving the cpufreq_global_kobject creation
> to late_initcall()) but I've not had any problems with it
> at least.
The problem is a bug in cpufreq that shouldn't point its syscore shutdown
callback pointer to cpufreq_suspend(), because the syscore stage is generally
too lat to call that function and I'm not sure why this has not been causing
any other issues to trigger (or maybe it did, but they were not reported).
Does the patch below work for you?
---
drivers/base/core.c | 3 +++
drivers/cpufreq/cpufreq.c | 10 ----------
2 files changed, 3 insertions(+), 10 deletions(-)
Index: linux-pm/drivers/cpufreq/cpufreq.c
===================================================================
--- linux-pm.orig/drivers/cpufreq/cpufreq.c
+++ linux-pm/drivers/cpufreq/cpufreq.c
@@ -2737,14 +2737,6 @@ int cpufreq_unregister_driver(struct cpu
}
EXPORT_SYMBOL_GPL(cpufreq_unregister_driver);
-/*
- * Stop cpufreq at shutdown to make sure it isn't holding any locks
- * or mutexes when secondary CPUs are halted.
- */
-static struct syscore_ops cpufreq_syscore_ops = {
- .shutdown = cpufreq_suspend,
-};
-
struct kobject *cpufreq_global_kobject;
EXPORT_SYMBOL(cpufreq_global_kobject);
@@ -2756,8 +2748,6 @@ static int __init cpufreq_core_init(void
cpufreq_global_kobject = kobject_create_and_add("cpufreq", &cpu_subsys.dev_root->kobj);
BUG_ON(!cpufreq_global_kobject);
- register_syscore_ops(&cpufreq_syscore_ops);
-
return 0;
}
module_param(off, int, 0444);
Index: linux-pm/drivers/base/core.c
===================================================================
--- linux-pm.orig/drivers/base/core.c
+++ linux-pm/drivers/base/core.c
@@ -9,6 +9,7 @@
*/
#include <linux/acpi.h>
+#include <linux/cpufreq.h>
#include <linux/device.h>
#include <linux/err.h>
#include <linux/fwnode.h>
@@ -3179,6 +3180,8 @@ void device_shutdown(void)
wait_for_device_probe();
device_block_probing();
+ cpufreq_suspend();
+
spin_lock(&devices_kset->list_lock);
/*
* Walk the devices list backward, shutting down each in turn.
next prev parent reply other threads:[~2019-10-03 15:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-03 14:08 [PATCH] cpufreq: Fix RCU reboot regression on x86 PIC machines Ville Syrjala
2019-10-03 15:05 ` Rafael J. Wysocki [this message]
2019-10-04 12:30 ` Ville Syrjälä
2019-10-06 15:34 ` Rafael J. Wysocki
2019-10-08 23:29 ` [PATCH] cpufreq: Avoid cpufreq_suspend() deadlock on system shutdown Rafael J. Wysocki
2019-10-10 6:53 ` Viresh Kumar
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=2393023.mJgu6cDs6C@kreacher \
--to=rjw@rjwysocki.net \
--cc=ak@linux.intel.com \
--cc=bp@alien8.de \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=ville.syrjala@linux.intel.com \
--cc=viresh.kumar@linaro.org \
/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;
as well as URLs for NNTP newsgroup(s).