public inbox for linux-pm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Srivatsa S. Bhat" <srivatsa.bhat@linux.vnet.ibm.com>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: "Jarzmik, Robert" <robert.jarzmik@intel.com>,
	"R, Durgadoss" <durgadoss.r@intel.com>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Subject: Re: S3, SMP non boot cpus and /sys/devices/system/cpu[1-9]/cpufreq/scaling_max_freq
Date: Tue, 14 May 2013 19:24:41 +0530	[thread overview]
Message-ID: <51924221.2080707@linux.vnet.ibm.com> (raw)
In-Reply-To: <2396135.fo7RrTTQCl@vostro.rjw.lan>

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>
---
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;
 	}




  reply	other threads:[~2013-05-14 13:57 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-13 13:01 S3, SMP non boot cpus and /sys/devices/system/cpu[1-9]/cpufreq/scaling_max_freq Jarzmik, Robert
2013-05-13 20:40 ` Srivatsa S. Bhat
2013-05-13 23:32   ` Rafael J. Wysocki
2013-05-14  9:06     ` Jarzmik, Robert
2013-05-14 10:09       ` Srivatsa S. Bhat
2013-05-14 10:22         ` Viresh Kumar
2013-05-14 10:27           ` Srivatsa S. Bhat
2013-05-14 11:22             ` Rafael J. Wysocki
2013-05-14 11:20               ` R, Durgadoss
2013-05-14 11:33                 ` Rafael J. Wysocki
2013-05-14 11:36                   ` R, Durgadoss
2013-05-14 11:54                     ` Jarzmik, Robert
2013-05-14 12:34                       ` Srivatsa S. Bhat
2013-05-14 13:00                         ` Rafael J. Wysocki
2013-05-14 13:54                           ` Srivatsa S. Bhat [this message]
2013-05-14 20:22                             ` Rafael J. Wysocki
2013-05-15  8:24                               ` Jarzmik, Robert
2013-05-15  8:37                               ` R, Durgadoss
2013-05-15  6:16                             ` Viresh Kumar
2013-05-15  6:30                               ` Srivatsa S. Bhat
2013-05-15  6:45                             ` Viresh Kumar
2013-05-15  7:33                               ` Srivatsa S. Bhat
2013-05-15  7:44                                 ` Viresh Kumar
2013-05-15  8:18                                   ` Srivatsa S. Bhat
2013-05-15 20:50                             ` Rafael J. Wysocki
2013-05-14 12:58                       ` Rafael J. Wysocki
2013-05-14 14:01                         ` Jarzmik, Robert
2013-05-14 14:16                           ` Srivatsa S. Bhat
2013-05-14 14:05                       ` Alan Stern
2013-05-15  9:20                         ` Jarzmik, Robert
2013-05-15 14:15                           ` Alan Stern

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=51924221.2080707@linux.vnet.ibm.com \
    --to=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=durgadoss.r@intel.com \
    --cc=linux-pm@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=robert.jarzmik@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