lkml.org 
[lkml]   [2013]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 7/8] cpufreq: Preserve policy structure across suspend/resume
On 07/15/2013 03:25 PM, Viresh Kumar wrote:
> Hi Srivatsa,
>
> I may be wrong but it looks something is wrong in this patch.
>
> On 12 July 2013 03:47, Srivatsa S. Bhat
> <srivatsa.bhat@linux.vnet.ibm.com> wrote:
>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
>
>> @@ -1239,29 +1263,40 @@ static int __cpufreq_remove_dev(struct device *dev,
>> if ((cpus == 1) && (cpufreq_driver->target))
>> __cpufreq_governor(data, CPUFREQ_GOV_POLICY_EXIT);
>>
>> - pr_debug("%s: removing link, cpu: %d\n", __func__, cpu);
>> - cpufreq_cpu_put(data);
>> + if (!frozen) {
>> + pr_debug("%s: removing link, cpu: %d\n", __func__, cpu);
>> + cpufreq_cpu_put(data);
>
> So, we don't decrement usage count here. But we are still increasing
> counts on cpufreq_add_dev after resume, isn't it?
>
> So, we wouldn't be able to free policy struct once all the cpus of a
> policy are removed after suspend/resume has happened once.
>

Actually even I was wondering about this while writing the patch and
I even tested shutdown after multiple suspend/resume cycles, to verify that
the refcount is messed up. But surprisingly, things worked just fine.

Logically there should've been a refcount mismatch and things should have
failed, but everything worked fine during my tests. Apart from suspend/resume
and shutdown tests, I even tried mixing a few regular CPU hotplug operations
(echo 0/1 to sysfs online files), but nothing stood out.

Sorry, I forgot to document this in the patch. Either the patch is wrong
or something else is silently fixing this up. Not sure what is the exact
situation.

Regards,
Srivatsa S. Bhat



\
 
 \ /
  Last update: 2013-07-15 12:42    [W:1.110 / U:0.240 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site