| Message ID | 51924221.2080707@linux.vnet.ibm.com (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
On Tuesday, May 14, 2013 07:24:41 PM Srivatsa S. Bhat wrote: > On 05/14/2013 06:30 PM, Rafael J. Wysocki wrote: > > On Tuesday, May 14, 2013 06:04:48 PM Srivatsa S. Bhat wrote: > >> On 05/14/2013 05:24 PM, Jarzmik, Robert wrote: > >>>> Okay, agreed after looking at this discussion ;) I am fine with the approach of kernel preserving permissions too. > >>> > >>> Ok, that's great, yet I don't see a clean solution here. This is > >>> the path I see and that bothers me in the S3 suspend path: > >>> cpufreq_sysfs_release > >>> kobject_cleanup > >>> kobject_release > >>> kobject_put > >>> __cpufreq_remove_dev > >>> cpufreq_cpu_callback > >>> notifier_call_chain > >>> __raw_notifier_call_chain > >>> __cpu_notify > >>> _cpu_down > >>> > >>> Here the sysfs attributes are destroyed. Cpu onlining will > >>> recreate them with root permissions. I don't see a good clean way > >>> to preserve permissions in sysfs across suspend/resume for > >>> deleted nodes. Do you ? > >>> > >>> And here we come to my actual worry : what is the technical clean > >>> way to solve this problem ? > >>> > >>> So far I have no idea (the cpufreq example is only a subset of > >>> the cases where it could happen). So if someone comes up with a > >>> good idea I'll volunteer to implement it :) > >>> > >> > >> Does the below (untested) patch help? I haven't spent time investigating > >> whether not doing the add_dev/remove_dev stuff during CPU hotplug in S3 path > >> will break something else. But it would be great if this works, since > >> its the simplest solution that I can think of. > > > > Well, what if the CPU doesn't come up during resume? > > > > Hmm, that's a good point. We will need to remove the sysfs files in that > case. The updated patch below uses CPU_UP_CANCELED_FROZEN notification > to do that. > > Regards, > Srivatsa S. Bhat > > -----------------------------------------------------------------------> > > From: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> > Subject: [PATCH v2] cpufreq: Preserve sysfs file permissions across suspend/resume > > The file permissions of cpufreq per-cpu sysfs files are not preserved across > suspend/resume because we internally go through the CPU Hotplug path which > reinitializes the file permissions on CPU online. > > But the user is not supposed to know that we are using CPU hotplug > internally within suspend/resume (IOW, the kernel should not silently wreck > the user-set file permissions across a suspend cycle). Therefore, we need to > preserve the file permissions as it is, across suspend/resume. > > The simplest way to achieve that is to just not touch the sysfs files at > all - ie., just ignore the CPU hotplug events in the suspend/resume path > (_FROZEN) in the cpufreq hotplug callback. > > Reported-by: Robert Jarzmik <robert.jarzmik@intel.com> > Reported-by: Durgadoss R <durgadoss.r@intel.com> > Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> It makes sense to me. Robert, Durga, does this work for you? Rafael > --- > v2: Use UP_CANCELED_FROZEN notification to delete the sysfs files if the > CPUs don't come up during resume. > > drivers/cpufreq/cpufreq.c | 4 +--- > drivers/cpufreq/cpufreq_stats.c | 7 ++++--- > 2 files changed, 5 insertions(+), 6 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index 1b8a48e..284ba63 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -1832,15 +1832,13 @@ static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb, > if (dev) { > switch (action) { > case CPU_ONLINE: > - case CPU_ONLINE_FROZEN: > cpufreq_add_dev(dev, NULL); > break; > case CPU_DOWN_PREPARE: > - case CPU_DOWN_PREPARE_FROZEN: > + case CPU_UP_CANCELED_FROZEN: > __cpufreq_remove_dev(dev, NULL); > break; > case CPU_DOWN_FAILED: > - case CPU_DOWN_FAILED_FROZEN: > cpufreq_add_dev(dev, NULL); > break; > } > diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c > index bfd6273..fb65dec 100644 > --- a/drivers/cpufreq/cpufreq_stats.c > +++ b/drivers/cpufreq/cpufreq_stats.c > @@ -349,15 +349,16 @@ static int __cpuinit cpufreq_stat_cpu_callback(struct notifier_block *nfb, > > switch (action) { > case CPU_ONLINE: > - case CPU_ONLINE_FROZEN: > cpufreq_update_policy(cpu); > break; > case CPU_DOWN_PREPARE: > - case CPU_DOWN_PREPARE_FROZEN: > cpufreq_stats_free_sysfs(cpu); > break; > case CPU_DEAD: > - case CPU_DEAD_FROZEN: > + cpufreq_stats_free_table(cpu); > + break; > + case CPU_UP_CANCELED_FROZEN: > + cpufreq_stats_free_sysfs(cpu); > cpufreq_stats_free_table(cpu); > break; > } > > >
On 14 May 2013 19:24, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote: > From: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> > Subject: [PATCH v2] cpufreq: Preserve sysfs file permissions across suspend/resume > > The file permissions of cpufreq per-cpu sysfs files are not preserved across > suspend/resume because we internally go through the CPU Hotplug path which > reinitializes the file permissions on CPU online. > > But the user is not supposed to know that we are using CPU hotplug > internally within suspend/resume (IOW, the kernel should not silently wreck > the user-set file permissions across a suspend cycle). Therefore, we need to > preserve the file permissions as it is, across suspend/resume. > > The simplest way to achieve that is to just not touch the sysfs files at > all - ie., just ignore the CPU hotplug events in the suspend/resume path > (_FROZEN) in the cpufreq hotplug callback. > > Reported-by: Robert Jarzmik <robert.jarzmik@intel.com> > Reported-by: Durgadoss R <durgadoss.r@intel.com> > Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> > --- > v2: Use UP_CANCELED_FROZEN notification to delete the sysfs files if the > CPUs don't come up during resume. Is it also possible that more cpus come up after resume? i.e. we had 2 cpus at suspend and 3 at resume? > drivers/cpufreq/cpufreq.c | 4 +--- > drivers/cpufreq/cpufreq_stats.c | 7 ++++--- > 2 files changed, 5 insertions(+), 6 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index 1b8a48e..284ba63 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -1832,15 +1832,13 @@ static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb, > if (dev) { > switch (action) { > case CPU_ONLINE: > - case CPU_ONLINE_FROZEN: > cpufreq_add_dev(dev, NULL); > break; > case CPU_DOWN_PREPARE: > - case CPU_DOWN_PREPARE_FROZEN: > + case CPU_UP_CANCELED_FROZEN: > __cpufreq_remove_dev(dev, NULL); > break; > case CPU_DOWN_FAILED: > - case CPU_DOWN_FAILED_FROZEN: > cpufreq_add_dev(dev, NULL); > break; I have forgotten meaning of these flags now :( So, CPU_ONLINE, CPU_DOWN_PREPARE and CPU_DOWN_FAILED are called when cpus are added/removed (but not for cpu_down in suspend resume)? and _FROZEN ones are only used for s2r/s2d? -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/15/2013 11:46 AM, Viresh Kumar wrote: > On 14 May 2013 19:24, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote: >> From: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> >> Subject: [PATCH v2] cpufreq: Preserve sysfs file permissions across suspend/resume >> >> The file permissions of cpufreq per-cpu sysfs files are not preserved across >> suspend/resume because we internally go through the CPU Hotplug path which >> reinitializes the file permissions on CPU online. >> >> But the user is not supposed to know that we are using CPU hotplug >> internally within suspend/resume (IOW, the kernel should not silently wreck >> the user-set file permissions across a suspend cycle). Therefore, we need to >> preserve the file permissions as it is, across suspend/resume. >> >> The simplest way to achieve that is to just not touch the sysfs files at >> all - ie., just ignore the CPU hotplug events in the suspend/resume path >> (_FROZEN) in the cpufreq hotplug callback. >> >> Reported-by: Robert Jarzmik <robert.jarzmik@intel.com> >> Reported-by: Durgadoss R <durgadoss.r@intel.com> >> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> >> --- >> v2: Use UP_CANCELED_FROZEN notification to delete the sysfs files if the >> CPUs don't come up during resume. > > Is it also possible that more cpus come up after resume? i.e. we had 2 cpus > at suspend and 3 at resume? Nope. That's not possible. While suspending we note down the online non-boot CPUs we have, in a cpumask, and take them offline. On resume, we try to online the CPUs in that cpumask. So there is no chance for more CPUs to come up during resume. > >> drivers/cpufreq/cpufreq.c | 4 +--- >> drivers/cpufreq/cpufreq_stats.c | 7 ++++--- >> 2 files changed, 5 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c >> index 1b8a48e..284ba63 100644 >> --- a/drivers/cpufreq/cpufreq.c >> +++ b/drivers/cpufreq/cpufreq.c >> @@ -1832,15 +1832,13 @@ static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb, >> if (dev) { >> switch (action) { >> case CPU_ONLINE: >> - case CPU_ONLINE_FROZEN: >> cpufreq_add_dev(dev, NULL); >> break; >> case CPU_DOWN_PREPARE: >> - case CPU_DOWN_PREPARE_FROZEN: >> + case CPU_UP_CANCELED_FROZEN: >> __cpufreq_remove_dev(dev, NULL); >> break; >> case CPU_DOWN_FAILED: >> - case CPU_DOWN_FAILED_FROZEN: >> cpufreq_add_dev(dev, NULL); >> break; > > I have forgotten meaning of these flags now :( Take a quick peek at kernel/cpu.c and include/linux/cpu.h and all those memories will come rushing back ;-) > So, CPU_ONLINE, CPU_DOWN_PREPARE and CPU_DOWN_FAILED > are called when cpus are added/removed (but not for cpu_down in suspend > resume)? and _FROZEN ones are only used for s2r/s2d? > Yes, that's right. For the suspend/resume and hibernate/restore case, all the notifiers use the _FROZEN flags. The regular hotplug notifications use the flags without the _FROZEN suffix. Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 14 May 2013 19:24, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote: > From: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> > Subject: [PATCH v2] cpufreq: Preserve sysfs file permissions across suspend/resume > > The file permissions of cpufreq per-cpu sysfs files are not preserved across > suspend/resume because we internally go through the CPU Hotplug path which > reinitializes the file permissions on CPU online. > > But the user is not supposed to know that we are using CPU hotplug > internally within suspend/resume (IOW, the kernel should not silently wreck > the user-set file permissions across a suspend cycle). Therefore, we need to > preserve the file permissions as it is, across suspend/resume. > > The simplest way to achieve that is to just not touch the sysfs files at > all - ie., just ignore the CPU hotplug events in the suspend/resume path > (_FROZEN) in the cpufreq hotplug callback. > > Reported-by: Robert Jarzmik <robert.jarzmik@intel.com> > Reported-by: Durgadoss R <durgadoss.r@intel.com> > Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> > --- > v2: Use UP_CANCELED_FROZEN notification to delete the sysfs files if the > CPUs don't come up during resume. > > drivers/cpufreq/cpufreq.c | 4 +--- > drivers/cpufreq/cpufreq_stats.c | 7 ++++--- > 2 files changed, 5 insertions(+), 6 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index 1b8a48e..284ba63 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -1832,15 +1832,13 @@ static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb, > if (dev) { > switch (action) { > case CPU_ONLINE: > - case CPU_ONLINE_FROZEN: > cpufreq_add_dev(dev, NULL); > break; > case CPU_DOWN_PREPARE: > - case CPU_DOWN_PREPARE_FROZEN: > + case CPU_UP_CANCELED_FROZEN: > __cpufreq_remove_dev(dev, NULL); > break; > case CPU_DOWN_FAILED: > - case CPU_DOWN_FAILED_FROZEN: > cpufreq_add_dev(dev, NULL); > break; > } > diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c > index bfd6273..fb65dec 100644 > --- a/drivers/cpufreq/cpufreq_stats.c > +++ b/drivers/cpufreq/cpufreq_stats.c > @@ -349,15 +349,16 @@ static int __cpuinit cpufreq_stat_cpu_callback(struct notifier_block *nfb, > > switch (action) { > case CPU_ONLINE: > - case CPU_ONLINE_FROZEN: > cpufreq_update_policy(cpu); > break; > case CPU_DOWN_PREPARE: > - case CPU_DOWN_PREPARE_FROZEN: > cpufreq_stats_free_sysfs(cpu); > break; > case CPU_DEAD: > - case CPU_DEAD_FROZEN: > + cpufreq_stats_free_table(cpu); > + break; > + case CPU_UP_CANCELED_FROZEN: > + cpufreq_stats_free_sysfs(cpu); > cpufreq_stats_free_table(cpu); > break; > } I accept that the patch makes things work but honestly speaking I didn't like it much :( As it looks like more of a hack than a proper solution. We are off-lining cpus but we are still keeping cpufreq directories (cpu/cpu*/cpufreq)... That goes against the basic rules... This works because there is no potential user between suspend/resume who can notice above issue. But that doesn't mean we write such code. On the other side, it looks difficult to preserve permissions by writing some complicated code to preserve and restore original settings for Suspend/resume. For now I can't imaging this breaking some stuff in cpufreq core. I don't want to but I have to (As i don't have a better solution): Acked-by: Viresh Kumar <viresh.kumar@linaro.org> -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/15/2013 12:15 PM, Viresh Kumar wrote: > On 14 May 2013 19:24, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote: >> From: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> >> Subject: [PATCH v2] cpufreq: Preserve sysfs file permissions across suspend/resume >> >> The file permissions of cpufreq per-cpu sysfs files are not preserved across >> suspend/resume because we internally go through the CPU Hotplug path which >> reinitializes the file permissions on CPU online. >> >> But the user is not supposed to know that we are using CPU hotplug >> internally within suspend/resume (IOW, the kernel should not silently wreck >> the user-set file permissions across a suspend cycle). Therefore, we need to >> preserve the file permissions as it is, across suspend/resume. >> >> The simplest way to achieve that is to just not touch the sysfs files at >> all - ie., just ignore the CPU hotplug events in the suspend/resume path >> (_FROZEN) in the cpufreq hotplug callback. >> >> Reported-by: Robert Jarzmik <robert.jarzmik@intel.com> >> Reported-by: Durgadoss R <durgadoss.r@intel.com> >> Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> >> --- >> v2: Use UP_CANCELED_FROZEN notification to delete the sysfs files if the >> CPUs don't come up during resume. >> >> drivers/cpufreq/cpufreq.c | 4 +--- >> drivers/cpufreq/cpufreq_stats.c | 7 ++++--- >> 2 files changed, 5 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c >> index 1b8a48e..284ba63 100644 >> --- a/drivers/cpufreq/cpufreq.c >> +++ b/drivers/cpufreq/cpufreq.c >> @@ -1832,15 +1832,13 @@ static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb, >> if (dev) { >> switch (action) { >> case CPU_ONLINE: >> - case CPU_ONLINE_FROZEN: >> cpufreq_add_dev(dev, NULL); >> break; >> case CPU_DOWN_PREPARE: >> - case CPU_DOWN_PREPARE_FROZEN: >> + case CPU_UP_CANCELED_FROZEN: >> __cpufreq_remove_dev(dev, NULL); >> break; >> case CPU_DOWN_FAILED: >> - case CPU_DOWN_FAILED_FROZEN: >> cpufreq_add_dev(dev, NULL); >> break; >> } >> diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c >> index bfd6273..fb65dec 100644 >> --- a/drivers/cpufreq/cpufreq_stats.c >> +++ b/drivers/cpufreq/cpufreq_stats.c >> @@ -349,15 +349,16 @@ static int __cpuinit cpufreq_stat_cpu_callback(struct notifier_block *nfb, >> >> switch (action) { >> case CPU_ONLINE: >> - case CPU_ONLINE_FROZEN: >> cpufreq_update_policy(cpu); >> break; >> case CPU_DOWN_PREPARE: >> - case CPU_DOWN_PREPARE_FROZEN: >> cpufreq_stats_free_sysfs(cpu); >> break; >> case CPU_DEAD: >> - case CPU_DEAD_FROZEN: >> + cpufreq_stats_free_table(cpu); >> + break; >> + case CPU_UP_CANCELED_FROZEN: >> + cpufreq_stats_free_sysfs(cpu); >> cpufreq_stats_free_table(cpu); >> break; >> } > > I accept that the patch makes things work but honestly speaking I > didn't like it much :( > > As it looks like more of a hack than a proper solution. We are off-lining > cpus but we are still keeping cpufreq directories (cpu/cpu*/cpufreq)... > That goes against the basic rules... > Why do you say that? We want to do *suspend/resume*, not *CPU hotplug*. So we do a "light" form of hotplug where only the most necessary things are done. Deleting all the sysfs files and recreating them on resume is a total waste of time anyway (and adds to the suspend/resume latency). The _FROZEN flags have been introduced and used for a long time now, for this very purpose : provide a way to make hotplug as light, and as smart as possible in the suspend/resume path, because our intention is to do *suspend/resume* and *not* hotplug per-se. It is only coincidental that we use hotplug internally in the those paths to get the job done easily. > This works because there is no potential user between suspend/resume > who can notice above issue. But that doesn't mean we write such code. > I disagree. There is absolutely nothing wrong here - we have *frozen* the userspace much before we did any of that! Why do you think we do that? IOW, it is not purely by chance that nobody is observing what we are doing in the suspend/resume path - we intentionally *froze* everybody! And until we thaw them in the resume path, nobody can see anything. And that is by design. Of course, freezing of tasks is important to restore them back on resume to the same state, but it serves higher-level purposes too, like this (ie., not surprising the user with unrelated events). That's part of the reason why its almost the first thing we do in the suspend path. > On the other side, it looks difficult to preserve permissions by writing some > complicated code to preserve and restore original settings for > Suspend/resume. > Think about it - nobody asked us to delete the sysfs files or wreck their settings and then worry about restoring them back; we were just asked to suspend and resume the system. Wrecking the settings is a side-effect of doing hotplug internally in the suspend/resume path. And that's exactly why we have the _FROZEN flags, to help us avoid shooting ourselves in the foot like that. We have used this solution of ignoring stuff to give the effect of preserving and restoring state, for much more serious stuff before. Take a look at commit 8f2f748b0656 (CPU hotplug, cpusets, suspend: Don't touch cpusets during suspend/resume). (But that commit had to be reworked later to handle a different problem, but that is not relevant here). There have been some clever optimizations too, that used similar methods : commit 3fb82d56ad0 (x86, suspend: Avoid unnecessary smp alternatives switch during suspend/resume). So IMHO this is a perfectly sane way to deal with suspend/resume with the infrastructure we have today. There is nothing wrong in doing this. Using the _FROZEN flags to speed up suspend/resume (and handle problems like this) is the closest approximation of the "inactive" state that Alan Stern described, that we have today in the kernel. > For now I can't imaging this breaking some stuff in cpufreq core. > What I was concerned was if there were any hidden dependencies between these functions which deal with sysfs and functions that deal with putting back the CPUs to the previously set frequencies upon resume (in case there are such things to be done at resume). Good to know that there are no such dependencies. > I don't want to but I have to (As i don't have a better solution): > > Acked-by: Viresh Kumar <viresh.kumar@linaro.org> > Thank you! I wish you had ACKed it more happily though ;-) Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 15 May 2013 13:03, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote:
> Thank you! I wish you had ACKed it more happily though ;-)
Hmm.. Your reasoning looks valid and mine wasn't right. So, consider it
a very happy Ack :)
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 05/15/2013 01:14 PM, Viresh Kumar wrote: > On 15 May 2013 13:03, Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> wrote: >> Thank you! I wish you had ACKed it more happily though ;-) > > Hmm.. Your reasoning looks valid and mine wasn't right. So, consider it > a very happy Ack :) > Awesome! Thank you :-) Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJhZmFlbCBKLiBXeXNvY2tpIFttYWls dG86cmp3QHNpc2sucGxdIA0KU2VudDogVHVlc2RheSwgTWF5IDE0LCAyMDEzIDEwOjIzIFBNDQpU bzogU3JpdmF0c2EgUy4gQmhhdDsgSmFyem1paywgUm9iZXJ0OyBSLCBEdXJnYWRvc3MNCkNjOiBW aXJlc2ggS3VtYXI7IGxpbnV4LXBtQHZnZXIua2VybmVsLm9yZw0KU3ViamVjdDogUmU6IFMzLCBT TVAgbm9uIGJvb3QgY3B1cyBhbmQgL3N5cy9kZXZpY2VzL3N5c3RlbS9jcHVbMS05XS9jcHVmcmVx L3NjYWxpbmdfbWF4X2ZyZXENCg0KPiBSb2JlcnQsIER1cmdhLCBkb2VzIHRoaXMgd29yayBmb3Ig eW91Pw0KWWVzIGl0IGRvZXMsIGV4YWN0bHkgdGhlIGZpeCBJIHdhcyBsb29raW5nIGZvci4NCg0K VGVzdGVkLWJ5OiBSb2JlcnQgSmFyem1payA8cm9iZXJ0LmphcnptaWtAaW50ZWwuY29tPg0KDQot LQ0KUm9iZXJ0DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpJbnRlbCBDb3Jwb3JhdGlvbiBTQVMgKEZyZW5jaCBz aW1wbGlmaWVkIGpvaW50IHN0b2NrIGNvbXBhbnkpClJlZ2lzdGVyZWQgaGVhZHF1YXJ0ZXJzOiAi TGVzIE1vbnRhbGV0cyItIDIsIHJ1ZSBkZSBQYXJpcywgCjkyMTk2IE1ldWRvbiBDZWRleCwgRnJh bmNlClJlZ2lzdHJhdGlvbiBOdW1iZXI6ICAzMDIgNDU2IDE5OSBSLkMuUy4gTkFOVEVSUkUKQ2Fw aXRhbDogNCw1NzIsMDAwIEV1cm9zCgpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIG1h eSBjb250YWluIGNvbmZpZGVudGlhbCBtYXRlcmlhbCBmb3IKdGhlIHNvbGUgdXNlIG9mIHRoZSBp bnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcgb3IgZGlzdHJpYnV0aW9uCmJ5IG90aGVy cyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVj aXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGFuZCBkZWxldGUgYWxsIGNvcGllcy4K -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSYWZhZWwgSi4gV3lzb2NraSBb bWFpbHRvOnJqd0BzaXNrLnBsXQ0KPiBTZW50OiBXZWRuZXNkYXksIE1heSAxNSwgMjAxMyAxOjUz IEFNDQo+IFRvOiBTcml2YXRzYSBTLiBCaGF0OyBKYXJ6bWlrLCBSb2JlcnQ7IFIsIER1cmdhZG9z cw0KPiBDYzogVmlyZXNoIEt1bWFyOyBsaW51eC1wbUB2Z2VyLmtlcm5lbC5vcmcNCj4gU3ViamVj dDogUmU6IFMzLCBTTVAgbm9uIGJvb3QgY3B1cyBhbmQgL3N5cy9kZXZpY2VzL3N5c3RlbS9jcHVb MS0NCj4gOV0vY3B1ZnJlcS9zY2FsaW5nX21heF9mcmVxDQo+IA0KPiBPbiBUdWVzZGF5LCBNYXkg MTQsIDIwMTMgMDc6MjQ6NDEgUE0gU3JpdmF0c2EgUy4gQmhhdCB3cm90ZToNCj4gPiBPbiAwNS8x NC8yMDEzIDA2OjMwIFBNLCBSYWZhZWwgSi4gV3lzb2NraSB3cm90ZToNCj4gPiA+IE9uIFR1ZXNk YXksIE1heSAxNCwgMjAxMyAwNjowNDo0OCBQTSBTcml2YXRzYSBTLiBCaGF0IHdyb3RlOg0KPiA+ ID4+IE9uIDA1LzE0LzIwMTMgMDU6MjQgUE0sIEphcnptaWssIFJvYmVydCB3cm90ZToNCj4gPiA+ Pj4+IE9rYXksIGFncmVlZCBhZnRlciBsb29raW5nIGF0IHRoaXMgZGlzY3Vzc2lvbiA7KSBJIGFt IGZpbmUgd2l0aCB0aGUNCj4gYXBwcm9hY2ggb2Yga2VybmVsIHByZXNlcnZpbmcgcGVybWlzc2lv bnMgdG9vLg0KPiA+ID4+Pg0KPiA+ID4+PiBPaywgdGhhdCdzIGdyZWF0LCB5ZXQgSSBkb24ndCBz ZWUgYSBjbGVhbiBzb2x1dGlvbiBoZXJlLiAgVGhpcyBpcw0KPiA+ID4+PiB0aGUgcGF0aCBJIHNl ZSBhbmQgdGhhdCBib3RoZXJzIG1lIGluIHRoZSBTMyBzdXNwZW5kIHBhdGg6DQo+ID4gPj4+IGNw dWZyZXFfc3lzZnNfcmVsZWFzZQ0KPiA+ID4+PiAgIGtvYmplY3RfY2xlYW51cA0KPiA+ID4+PiAg ICAga29iamVjdF9yZWxlYXNlDQo+ID4gPj4+ICAgICAgIGtvYmplY3RfcHV0DQo+ID4gPj4+ICAg ICAgICAgX19jcHVmcmVxX3JlbW92ZV9kZXYNCj4gPiA+Pj4gICAgICAgICAgIGNwdWZyZXFfY3B1 X2NhbGxiYWNrDQo+ID4gPj4+ICAgICAgICAgICAgIG5vdGlmaWVyX2NhbGxfY2hhaW4NCj4gPiA+ Pj4gICAgICAgICAgICAgICBfX3Jhd19ub3RpZmllcl9jYWxsX2NoYWluDQo+ID4gPj4+ICAgICAg ICAgICAgICAgICBfX2NwdV9ub3RpZnkNCj4gPiA+Pj4gICAgICAgICAgICAgICAgICAgX2NwdV9k b3duDQo+ID4gPj4+DQo+ID4gPj4+IEhlcmUgdGhlIHN5c2ZzIGF0dHJpYnV0ZXMgYXJlIGRlc3Ry b3llZC4gQ3B1IG9ubGluaW5nIHdpbGwNCj4gPiA+Pj4gcmVjcmVhdGUgdGhlbSB3aXRoIHJvb3Qg cGVybWlzc2lvbnMuIEkgZG9uJ3Qgc2VlIGEgZ29vZCBjbGVhbiB3YXkNCj4gPiA+Pj4gdG8gcHJl c2VydmUgcGVybWlzc2lvbnMgaW4gc3lzZnMgYWNyb3NzIHN1c3BlbmQvcmVzdW1lIGZvcg0KPiA+ ID4+PiBkZWxldGVkIG5vZGVzLiBEbyB5b3UgPw0KPiA+ID4+Pg0KPiA+ID4+PiBBbmQgaGVyZSB3 ZSBjb21lIHRvIG15IGFjdHVhbCB3b3JyeSA6IHdoYXQgaXMgdGhlIHRlY2huaWNhbCBjbGVhbg0K PiA+ID4+PiB3YXkgdG8gc29sdmUgdGhpcyBwcm9ibGVtID8NCj4gPiA+Pj4NCj4gPiA+Pj4gU28g ZmFyIEkgaGF2ZSBubyBpZGVhICh0aGUgY3B1ZnJlcSBleGFtcGxlIGlzIG9ubHkgYSBzdWJzZXQg b2YNCj4gPiA+Pj4gdGhlIGNhc2VzIHdoZXJlIGl0IGNvdWxkIGhhcHBlbikuIFNvIGlmIHNvbWVv bmUgY29tZXMgdXAgd2l0aCBhDQo+ID4gPj4+IGdvb2QgaWRlYSBJJ2xsIHZvbHVudGVlciB0byBp bXBsZW1lbnQgaXQgOikNCj4gPiA+Pj4NCj4gPiA+Pg0KPiA+ID4+IERvZXMgdGhlIGJlbG93ICh1 bnRlc3RlZCkgcGF0Y2ggaGVscD8gSSBoYXZlbid0IHNwZW50IHRpbWUNCj4gaW52ZXN0aWdhdGlu Zw0KPiA+ID4+IHdoZXRoZXIgbm90IGRvaW5nIHRoZSBhZGRfZGV2L3JlbW92ZV9kZXYgc3R1ZmYg ZHVyaW5nIENQVSBob3RwbHVnDQo+IGluIFMzIHBhdGgNCj4gPiA+PiB3aWxsIGJyZWFrIHNvbWV0 aGluZyBlbHNlLiBCdXQgaXQgd291bGQgYmUgZ3JlYXQgaWYgdGhpcyB3b3Jrcywgc2luY2UNCj4g PiA+PiBpdHMgdGhlIHNpbXBsZXN0IHNvbHV0aW9uIHRoYXQgSSBjYW4gdGhpbmsgb2YuDQo+ID4g Pg0KPiA+ID4gV2VsbCwgd2hhdCBpZiB0aGUgQ1BVIGRvZXNuJ3QgY29tZSB1cCBkdXJpbmcgcmVz dW1lPw0KPiA+ID4NCj4gPg0KPiA+IEhtbSwgdGhhdCdzIGEgZ29vZCBwb2ludC4gV2Ugd2lsbCBu ZWVkIHRvIHJlbW92ZSB0aGUgc3lzZnMgZmlsZXMgaW4gdGhhdA0KPiA+IGNhc2UuIFRoZSB1cGRh dGVkIHBhdGNoIGJlbG93IHVzZXMgQ1BVX1VQX0NBTkNFTEVEX0ZST1pFTg0KPiBub3RpZmljYXRp b24NCj4gPiB0byBkbyB0aGF0Lg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiBTcml2YXRzYSBTLiBC aGF0DQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4NCj4gPg0KPiA+IEZyb206IFNyaXZhdHNhIFMu IEJoYXQgPHNyaXZhdHNhLmJoYXRAbGludXgudm5ldC5pYm0uY29tPg0KPiA+IFN1YmplY3Q6IFtQ QVRDSCB2Ml0gY3B1ZnJlcTogUHJlc2VydmUgc3lzZnMgZmlsZSBwZXJtaXNzaW9ucyBhY3Jvc3MN Cj4gc3VzcGVuZC9yZXN1bWUNCj4gPg0KPiA+IFRoZSBmaWxlIHBlcm1pc3Npb25zIG9mIGNwdWZy ZXEgcGVyLWNwdSBzeXNmcyBmaWxlcyBhcmUgbm90IHByZXNlcnZlZCBhY3Jvc3MNCj4gPiBzdXNw ZW5kL3Jlc3VtZSBiZWNhdXNlIHdlIGludGVybmFsbHkgZ28gdGhyb3VnaCB0aGUgQ1BVIEhvdHBs dWcgcGF0aA0KPiB3aGljaA0KPiA+IHJlaW5pdGlhbGl6ZXMgdGhlIGZpbGUgcGVybWlzc2lvbnMg b24gQ1BVIG9ubGluZS4NCj4gPg0KPiA+IEJ1dCB0aGUgdXNlciBpcyBub3Qgc3VwcG9zZWQgdG8g a25vdyB0aGF0IHdlIGFyZSB1c2luZyBDUFUgaG90cGx1Zw0KPiA+IGludGVybmFsbHkgd2l0aGlu IHN1c3BlbmQvcmVzdW1lIChJT1csIHRoZSBrZXJuZWwgc2hvdWxkIG5vdCBzaWxlbnRseQ0KPiB3 cmVjaw0KPiA+IHRoZSB1c2VyLXNldCBmaWxlIHBlcm1pc3Npb25zIGFjcm9zcyBhIHN1c3BlbmQg Y3ljbGUpLiBUaGVyZWZvcmUsIHdlIG5lZWQNCj4gdG8NCj4gPiBwcmVzZXJ2ZSB0aGUgZmlsZSBw ZXJtaXNzaW9ucyBhcyBpdCBpcywgYWNyb3NzIHN1c3BlbmQvcmVzdW1lLg0KPiA+DQo+ID4gVGhl IHNpbXBsZXN0IHdheSB0byBhY2hpZXZlIHRoYXQgaXMgdG8ganVzdCBub3QgdG91Y2ggdGhlIHN5 c2ZzIGZpbGVzIGF0DQo+ID4gYWxsIC0gaWUuLCBqdXN0IGlnbm9yZSB0aGUgQ1BVIGhvdHBsdWcg ZXZlbnRzIGluIHRoZSBzdXNwZW5kL3Jlc3VtZSBwYXRoDQo+ID4gKF9GUk9aRU4pIGluIHRoZSBj cHVmcmVxIGhvdHBsdWcgY2FsbGJhY2suDQo+ID4NCj4gPiBSZXBvcnRlZC1ieTogUm9iZXJ0IEph cnptaWsgPHJvYmVydC5qYXJ6bWlrQGludGVsLmNvbT4NCj4gPiBSZXBvcnRlZC1ieTogRHVyZ2Fk b3NzIFIgPGR1cmdhZG9zcy5yQGludGVsLmNvbT4NCj4gPiBTaWduZWQtb2ZmLWJ5OiBTcml2YXRz YSBTLiBCaGF0IDxzcml2YXRzYS5iaGF0QGxpbnV4LnZuZXQuaWJtLmNvbT4NCj4gDQo+IEl0IG1h a2VzIHNlbnNlIHRvIG1lLg0KPiANCj4gUm9iZXJ0LCBEdXJnYSwgZG9lcyB0aGlzIHdvcmsgZm9y IHlvdT8NCg0KWWVzLCBUaGUgdjIgdmVyc2lvbiBvZiB0aGUgcGF0Y2ggd29ya3MuDQpUaGFuayB5 b3UgU3JpdmF0c2EgOykNCg0KVGVzdGVkLWJ5OiBEdXJnYWRvc3MgUiA8ZHVyZ2Fkb3NzLnJAaW50 ZWwuY29tPg0KDQpUaGFua3MsDQpEdXJnYQ0KPiANCj4gUmFmYWVsDQo+IA0KPiANCj4gPiAtLS0N Cj4gPiB2MjogVXNlIFVQX0NBTkNFTEVEX0ZST1pFTiBub3RpZmljYXRpb24gdG8gZGVsZXRlIHRo ZSBzeXNmcyBmaWxlcyBpZiB0aGUNCj4gPiBDUFVzIGRvbid0IGNvbWUgdXAgZHVyaW5nIHJlc3Vt ZS4NCj4gPg0KPiA+ICBkcml2ZXJzL2NwdWZyZXEvY3B1ZnJlcS5jICAgICAgIHwgICAgNCArLS0t DQo+ID4gIGRyaXZlcnMvY3B1ZnJlcS9jcHVmcmVxX3N0YXRzLmMgfCAgICA3ICsrKystLS0NCj4g PiAgMiBmaWxlcyBjaGFuZ2VkLCA1IGluc2VydGlvbnMoKyksIDYgZGVsZXRpb25zKC0pDQo+ID4N Cj4gPiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9jcHVmcmVxL2NwdWZyZXEuYyBiL2RyaXZlcnMvY3B1 ZnJlcS9jcHVmcmVxLmMNCj4gPiBpbmRleCAxYjhhNDhlLi4yODRiYTYzIDEwMDY0NA0KPiA+IC0t LSBhL2RyaXZlcnMvY3B1ZnJlcS9jcHVmcmVxLmMNCj4gPiArKysgYi9kcml2ZXJzL2NwdWZyZXEv Y3B1ZnJlcS5jDQo+ID4gQEAgLTE4MzIsMTUgKzE4MzIsMTMgQEAgc3RhdGljIGludCBfX2NwdWlu aXQgY3B1ZnJlcV9jcHVfY2FsbGJhY2soc3RydWN0DQo+IG5vdGlmaWVyX2Jsb2NrICpuZmIsDQo+ ID4gIAlpZiAoZGV2KSB7DQo+ID4gIAkJc3dpdGNoIChhY3Rpb24pIHsNCj4gPiAgCQljYXNlIENQ VV9PTkxJTkU6DQo+ID4gLQkJY2FzZSBDUFVfT05MSU5FX0ZST1pFTjoNCj4gPiAgCQkJY3B1ZnJl cV9hZGRfZGV2KGRldiwgTlVMTCk7DQo+ID4gIAkJCWJyZWFrOw0KPiA+ICAJCWNhc2UgQ1BVX0RP V05fUFJFUEFSRToNCj4gPiAtCQljYXNlIENQVV9ET1dOX1BSRVBBUkVfRlJPWkVOOg0KPiA+ICsJ CWNhc2UgQ1BVX1VQX0NBTkNFTEVEX0ZST1pFTjoNCj4gPiAgCQkJX19jcHVmcmVxX3JlbW92ZV9k ZXYoZGV2LCBOVUxMKTsNCj4gPiAgCQkJYnJlYWs7DQo+ID4gIAkJY2FzZSBDUFVfRE9XTl9GQUlM RUQ6DQo+ID4gLQkJY2FzZSBDUFVfRE9XTl9GQUlMRURfRlJPWkVOOg0KPiA+ICAJCQljcHVmcmVx X2FkZF9kZXYoZGV2LCBOVUxMKTsNCj4gPiAgCQkJYnJlYWs7DQo+ID4gIAkJfQ0KPiA+IGRpZmYg LS1naXQgYS9kcml2ZXJzL2NwdWZyZXEvY3B1ZnJlcV9zdGF0cy5jDQo+IGIvZHJpdmVycy9jcHVm cmVxL2NwdWZyZXFfc3RhdHMuYw0KPiA+IGluZGV4IGJmZDYyNzMuLmZiNjVkZWMgMTAwNjQ0DQo+ ID4gLS0tIGEvZHJpdmVycy9jcHVmcmVxL2NwdWZyZXFfc3RhdHMuYw0KPiA+ICsrKyBiL2RyaXZl cnMvY3B1ZnJlcS9jcHVmcmVxX3N0YXRzLmMNCj4gPiBAQCAtMzQ5LDE1ICszNDksMTYgQEAgc3Rh dGljIGludCBfX2NwdWluaXQNCj4gY3B1ZnJlcV9zdGF0X2NwdV9jYWxsYmFjayhzdHJ1Y3Qgbm90 aWZpZXJfYmxvY2sgKm5mYiwNCj4gPg0KPiA+ICAJc3dpdGNoIChhY3Rpb24pIHsNCj4gPiAgCWNh c2UgQ1BVX09OTElORToNCj4gPiAtCWNhc2UgQ1BVX09OTElORV9GUk9aRU46DQo+ID4gIAkJY3B1 ZnJlcV91cGRhdGVfcG9saWN5KGNwdSk7DQo+ID4gIAkJYnJlYWs7DQo+ID4gIAljYXNlIENQVV9E T1dOX1BSRVBBUkU6DQo+ID4gLQljYXNlIENQVV9ET1dOX1BSRVBBUkVfRlJPWkVOOg0KPiA+ICAJ CWNwdWZyZXFfc3RhdHNfZnJlZV9zeXNmcyhjcHUpOw0KPiA+ICAJCWJyZWFrOw0KPiA+ICAJY2Fz ZSBDUFVfREVBRDoNCj4gPiAtCWNhc2UgQ1BVX0RFQURfRlJPWkVOOg0KPiA+ICsJCWNwdWZyZXFf c3RhdHNfZnJlZV90YWJsZShjcHUpOw0KPiA+ICsJCWJyZWFrOw0KPiA+ICsJY2FzZSBDUFVfVVBf Q0FOQ0VMRURfRlJPWkVOOg0KPiA+ICsJCWNwdWZyZXFfc3RhdHNfZnJlZV9zeXNmcyhjcHUpOw0K PiA+ICAJCWNwdWZyZXFfc3RhdHNfZnJlZV90YWJsZShjcHUpOw0KPiA+ICAJCWJyZWFrOw0KPiA+ ICAJfQ0KPiA+DQo+ID4NCj4gPg0KPiAtLQ0KPiBJIHNwZWFrIG9ubHkgZm9yIG15c2VsZi4NCj4g UmFmYWVsIEouIFd5c29ja2ksIEludGVsIE9wZW4gU291cmNlIFRlY2hub2xvZ3kgQ2VudGVyLg0K -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday, May 14, 2013 07:24:41 PM Srivatsa S. Bhat wrote: > On 05/14/2013 06:30 PM, Rafael J. Wysocki wrote: > > On Tuesday, May 14, 2013 06:04:48 PM Srivatsa S. Bhat wrote: > >> On 05/14/2013 05:24 PM, Jarzmik, Robert wrote: > >>>> Okay, agreed after looking at this discussion ;) I am fine with the approach of kernel preserving permissions too. > >>> > >>> Ok, that's great, yet I don't see a clean solution here. This is > >>> the path I see and that bothers me in the S3 suspend path: > >>> cpufreq_sysfs_release > >>> kobject_cleanup > >>> kobject_release > >>> kobject_put > >>> __cpufreq_remove_dev > >>> cpufreq_cpu_callback > >>> notifier_call_chain > >>> __raw_notifier_call_chain > >>> __cpu_notify > >>> _cpu_down > >>> > >>> Here the sysfs attributes are destroyed. Cpu onlining will > >>> recreate them with root permissions. I don't see a good clean way > >>> to preserve permissions in sysfs across suspend/resume for > >>> deleted nodes. Do you ? > >>> > >>> And here we come to my actual worry : what is the technical clean > >>> way to solve this problem ? > >>> > >>> So far I have no idea (the cpufreq example is only a subset of > >>> the cases where it could happen). So if someone comes up with a > >>> good idea I'll volunteer to implement it :) > >>> > >> > >> Does the below (untested) patch help? I haven't spent time investigating > >> whether not doing the add_dev/remove_dev stuff during CPU hotplug in S3 path > >> will break something else. But it would be great if this works, since > >> its the simplest solution that I can think of. > > > > Well, what if the CPU doesn't come up during resume? > > > > Hmm, that's a good point. We will need to remove the sysfs files in that > case. The updated patch below uses CPU_UP_CANCELED_FROZEN notification > to do that. > > Regards, > Srivatsa S. Bhat > > -----------------------------------------------------------------------> > > From: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> > Subject: [PATCH v2] cpufreq: Preserve sysfs file permissions across suspend/resume > > The file permissions of cpufreq per-cpu sysfs files are not preserved across > suspend/resume because we internally go through the CPU Hotplug path which > reinitializes the file permissions on CPU online. > > But the user is not supposed to know that we are using CPU hotplug > internally within suspend/resume (IOW, the kernel should not silently wreck > the user-set file permissions across a suspend cycle). Therefore, we need to > preserve the file permissions as it is, across suspend/resume. > > The simplest way to achieve that is to just not touch the sysfs files at > all - ie., just ignore the CPU hotplug events in the suspend/resume path > (_FROZEN) in the cpufreq hotplug callback. > > Reported-by: Robert Jarzmik <robert.jarzmik@intel.com> > Reported-by: Durgadoss R <durgadoss.r@intel.com> > Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Applied to linux-pm.git/linux-next as v3.10-rc2 material. Thanks, Rafael > --- > v2: Use UP_CANCELED_FROZEN notification to delete the sysfs files if the > CPUs don't come up during resume. > > drivers/cpufreq/cpufreq.c | 4 +--- > drivers/cpufreq/cpufreq_stats.c | 7 ++++--- > 2 files changed, 5 insertions(+), 6 deletions(-) > > diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c > index 1b8a48e..284ba63 100644 > --- a/drivers/cpufreq/cpufreq.c > +++ b/drivers/cpufreq/cpufreq.c > @@ -1832,15 +1832,13 @@ static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb, > if (dev) { > switch (action) { > case CPU_ONLINE: > - case CPU_ONLINE_FROZEN: > cpufreq_add_dev(dev, NULL); > break; > case CPU_DOWN_PREPARE: > - case CPU_DOWN_PREPARE_FROZEN: > + case CPU_UP_CANCELED_FROZEN: > __cpufreq_remove_dev(dev, NULL); > break; > case CPU_DOWN_FAILED: > - case CPU_DOWN_FAILED_FROZEN: > cpufreq_add_dev(dev, NULL); > break; > } > diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c > index bfd6273..fb65dec 100644 > --- a/drivers/cpufreq/cpufreq_stats.c > +++ b/drivers/cpufreq/cpufreq_stats.c > @@ -349,15 +349,16 @@ static int __cpuinit cpufreq_stat_cpu_callback(struct notifier_block *nfb, > > switch (action) { > case CPU_ONLINE: > - case CPU_ONLINE_FROZEN: > cpufreq_update_policy(cpu); > break; > case CPU_DOWN_PREPARE: > - case CPU_DOWN_PREPARE_FROZEN: > cpufreq_stats_free_sysfs(cpu); > break; > case CPU_DEAD: > - case CPU_DEAD_FROZEN: > + cpufreq_stats_free_table(cpu); > + break; > + case CPU_UP_CANCELED_FROZEN: > + cpufreq_stats_free_sysfs(cpu); > cpufreq_stats_free_table(cpu); > break; > } > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 1b8a48e..284ba63 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -1832,15 +1832,13 @@ static int __cpuinit cpufreq_cpu_callback(struct notifier_block *nfb, if (dev) { switch (action) { case CPU_ONLINE: - case CPU_ONLINE_FROZEN: cpufreq_add_dev(dev, NULL); break; case CPU_DOWN_PREPARE: - case CPU_DOWN_PREPARE_FROZEN: + case CPU_UP_CANCELED_FROZEN: __cpufreq_remove_dev(dev, NULL); break; case CPU_DOWN_FAILED: - case CPU_DOWN_FAILED_FROZEN: cpufreq_add_dev(dev, NULL); break; } diff --git a/drivers/cpufreq/cpufreq_stats.c b/drivers/cpufreq/cpufreq_stats.c index bfd6273..fb65dec 100644 --- a/drivers/cpufreq/cpufreq_stats.c +++ b/drivers/cpufreq/cpufreq_stats.c @@ -349,15 +349,16 @@ static int __cpuinit cpufreq_stat_cpu_callback(struct notifier_block *nfb, switch (action) { case CPU_ONLINE: - case CPU_ONLINE_FROZEN: cpufreq_update_policy(cpu); break; case CPU_DOWN_PREPARE: - case CPU_DOWN_PREPARE_FROZEN: cpufreq_stats_free_sysfs(cpu); break; case CPU_DEAD: - case CPU_DEAD_FROZEN: + cpufreq_stats_free_table(cpu); + break; + case CPU_UP_CANCELED_FROZEN: + cpufreq_stats_free_sysfs(cpu); cpufreq_stats_free_table(cpu); break; }