From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
"Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Michael Wang <wangyun@linux.vnet.ibm.com>,
Jiri Kosina <jkosina@suse.cz>, Borislav Petkov <bp@alien8.de>,
Viresh Kumar <viresh.kumar@linaro.org>,
linux-kernel@vger.kernel.org, cpufreq@vger.kernel.org,
linux-pm@vger.kernel.org,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Subject: Re: [LOCKDEP] cpufreq: possible circular locking dependency detected
Date: Mon, 15 Jul 2013 19:02:09 +0530 [thread overview]
Message-ID: <51E3F9D9.8060403@linux.vnet.ibm.com> (raw)
In-Reply-To: <51E3F6EB.2050807@linux.vnet.ibm.com>
On 07/15/2013 06:49 PM, Srivatsa S. Bhat wrote:
[...]
> The intent of this commit was to avoid warnings during CPU hotplug, which
> indicated that offline CPUs were getting IPIs from the cpufreq governor's
> work items. But the real root-cause of that problem was commit a66b2e5
> (cpufreq: Preserve sysfs files across suspend/resume) because it totally
> skipped all the cpufreq callbacks during CPU hotplug in the suspend/resume
> path, and hence it never actually shut down the cpufreq governor's worker
> threads during CPU offline in the suspend/resume path.
>
> Reflecting back, the reason why we never suspected that commit as the
> root-cause earlier, was that the original issue was reported with just the
> halt command and nobody had brought in suspend/resume to the equation.
>
> The reason for _that_ in turn, it turns out is that, earlier halt/shutdown
> was being done by disabling non-boot CPUs while tasks were frozen, just like
> suspend/resume.... but commit cf7df378a (reboot: rigrate shutdown/reboot to
> boot cpu) which came somewhere along that very same time changed that logic:
> shutdown/halt no longer takes CPUs offline.
> Thus, the test-cases for reproducing the bug were vastly different and thus
> we went totally off the trail.
>
> Overall, it was one hell of a confusion with so many commits affecting
> each other and also affecting the symptoms of the problems in subtle
> ways. Finally, now since the original problematic commit (a66b2e5) has been
> completely reverted, revert this intermediate fix too (2f7021a), to fix the
> CPU hotplug deadlock. Phew!
>
> Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> Reported-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Forgot to add: If this solves the issues people are facing, IMHO this should
also be CC'ed to stable just like the full-revert of a66b2e5, .
Regards,
Srivatsa S. Bhat
> ---
>
> drivers/cpufreq/cpufreq_governor.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c
> index 4645876..7b839a8 100644
> --- a/drivers/cpufreq/cpufreq_governor.c
> +++ b/drivers/cpufreq/cpufreq_governor.c
> @@ -25,7 +25,6 @@
> #include <linux/slab.h>
> #include <linux/types.h>
> #include <linux/workqueue.h>
> -#include <linux/cpu.h>
>
> #include "cpufreq_governor.h"
>
> @@ -137,10 +136,8 @@ void gov_queue_work(struct dbs_data *dbs_data, struct cpufreq_policy *policy,
> if (!all_cpus) {
> __gov_queue_work(smp_processor_id(), dbs_data, delay);
> } else {
> - get_online_cpus();
> for_each_cpu(i, policy->cpus)
> __gov_queue_work(i, dbs_data, delay);
> - put_online_cpus();
> }
> }
> EXPORT_SYMBOL_GPL(gov_queue_work);
>
next prev parent reply other threads:[~2013-07-15 13:32 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-25 21:15 [LOCKDEP] cpufreq: possible circular locking dependency detected Sergey Senozhatsky
2013-06-28 4:43 ` Viresh Kumar
2013-06-28 7:44 ` [RFC PATCH] cpu hotplug: rework cpu_hotplug locking (was [LOCKDEP] cpufreq: possible circular locking dependency detected) Sergey Senozhatsky
2013-06-28 9:31 ` Srivatsa S. Bhat
2013-06-28 10:04 ` Sergey Senozhatsky
2013-06-28 14:13 ` Srivatsa S. Bhat
2013-06-29 7:35 ` Sergey Senozhatsky
2013-07-01 4:42 ` [LOCKDEP] cpufreq: possible circular locking dependency detected Michael Wang
2013-07-10 23:13 ` Sergey Senozhatsky
2013-07-11 2:43 ` Michael Wang
2013-07-11 8:22 ` Sergey Senozhatsky
2013-07-11 8:47 ` Michael Wang
2013-07-11 8:48 ` Michael Wang
2013-07-11 11:47 ` Bartlomiej Zolnierkiewicz
2013-07-12 2:19 ` Michael Wang
2013-07-11 9:01 ` Sergey Senozhatsky
2013-07-14 11:47 ` Sergey Senozhatsky
2013-07-14 12:06 ` Sergey Senozhatsky
2013-07-15 3:50 ` Michael Wang
2013-07-15 7:52 ` Michael Wang
2013-07-15 8:29 ` Sergey Senozhatsky
2013-07-15 13:19 ` Srivatsa S. Bhat
2013-07-15 13:32 ` Srivatsa S. Bhat [this message]
2013-07-15 20:49 ` Peter Wu
2013-07-16 8:29 ` Srivatsa S. Bhat
2013-07-15 23:20 ` Sergey Senozhatsky
2013-07-16 8:33 ` Srivatsa S. Bhat
2013-07-16 10:44 ` Sergey Senozhatsky
2013-07-16 15:19 ` Srivatsa S. Bhat
2013-07-16 21:29 ` Rafael J. Wysocki
2013-07-16 2:19 ` Michael Wang
2013-07-15 2:42 ` Michael Wang
2013-07-14 15:56 ` Rafael J. Wysocki
2013-07-15 2:46 ` Michael Wang
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=51E3F9D9.8060403@linux.vnet.ibm.com \
--to=srivatsa.bhat@linux.vnet.ibm.com \
--cc=b.zolnierkie@samsung.com \
--cc=bp@alien8.de \
--cc=cpufreq@vger.kernel.org \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=sergey.senozhatsky@gmail.com \
--cc=viresh.kumar@linaro.org \
--cc=wangyun@linux.vnet.ibm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.