From: Stephen Warren <swarren@wwwdotorg.org>
To: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
cpufreq <cpufreq@vger.kernel.org>
Subject: Re: cpufreq_stats NULL deref on second system suspend
Date: Thu, 12 Sep 2013 09:55:14 -0600 [thread overview]
Message-ID: <5231E3E2.1050101@wwwdotorg.org> (raw)
In-Reply-To: <52315E9A.3000607@linux.vnet.ibm.com>
On 09/12/2013 12:26 AM, Srivatsa S. Bhat wrote:
> On 09/12/2013 11:22 AM, Viresh Kumar wrote:
...
>> Now coming back to the ideas I have...
>> Same code will work if hotplug sequence is fixed a bit. Why aren't we doing
>> exact opposite of suspend in resume?
>>
>> We are removing CPUs (leaving the boot cpu) in ascending order and then
>> adding them back in same order.. Why?
>>
>> Why not remove CPUs in descending order and add in ascending order? Or
>> remove in ascending order and add in descending order?
>
> I had the same thought when solving this bug.. We have had similar issues with
> CPU hotplug notifiers too: why are they invoked in the same order during both
> CPU down and up, instead of reversing the order? I even had a patchset to perform
> reverse-invocation of notifiers.. http://lwn.net/Articles/508072/
> ... but people didn't find that very compelling to have.
I'm not sure if you're talking about the order the CPUs get plugged back
in after resume, or the order of the (pair of?) notifiers that gets
called for each individual CPU.
Sorry if this is blindingly obvious, but with CPU hotplug, I can
manually unplug/re-plug CPUs in any order I feel like, and cpufreq had
better work if I do that. Given that, I don't think there's any
particular need for suspend/resume to unplug/re-plug CPUs in any
particular order for correctness at least, although perhaps it'd be nice
cosmetically for some reason?
next prev parent reply other threads:[~2013-09-12 15:55 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <522E1FEF.6080803@wwwdotorg.org>
[not found] ` <1775778.MeiRhuYy7o@vostro.rjw.lan>
[not found] ` <522F86AD.6010603@wwwdotorg.org>
[not found] ` <2521560.SfeNbV74nj@vostro.rjw.lan>
2013-09-11 10:21 ` cpufreq_stats NULL deref on second system suspend Srivatsa S. Bhat
2013-09-11 10:44 ` Viresh Kumar
2013-09-11 10:45 ` Viresh Kumar
2013-09-11 11:14 ` Srivatsa S. Bhat
2013-09-11 11:59 ` Viresh Kumar
2013-09-11 13:56 ` Srivatsa S. Bhat
2013-09-12 5:52 ` Viresh Kumar
2013-09-12 6:26 ` Srivatsa S. Bhat
2013-09-12 6:41 ` Viresh Kumar
2013-09-12 6:46 ` Srivatsa S. Bhat
2013-09-12 6:52 ` Viresh Kumar
2013-09-12 7:14 ` Srivatsa S. Bhat
2013-09-12 15:55 ` Stephen Warren [this message]
2013-09-12 17:26 ` Srivatsa S. Bhat
2013-09-13 4:26 ` Viresh Kumar
2013-09-11 11:10 ` Srivatsa S. Bhat
2013-09-11 11:15 ` Viresh Kumar
2013-09-11 11:17 ` Srivatsa S. Bhat
2013-09-11 11:41 ` Viresh Kumar
2013-09-11 11:09 ` Srivatsa S. Bhat
2013-09-11 16:05 ` Stephen Warren
2013-09-11 18:03 ` Srivatsa S. Bhat
2013-09-11 18:42 ` Srivatsa S. Bhat
2013-09-11 19:03 ` Stephen Warren
2013-09-11 19:46 ` Srivatsa S. Bhat
2013-09-11 20:07 ` Stephen Warren
2013-09-11 20:05 ` Srivatsa S. Bhat
2013-09-12 6:04 ` Viresh Kumar
2013-09-12 6:00 ` Viresh Kumar
2013-09-12 5:58 ` 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=5231E3E2.1050101@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=cpufreq@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=srivatsa.bhat@linux.vnet.ibm.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