linux.git/drivers/cpufreq/cpufreq.c, branch v4.1

cpufreq: Schedule work for the first-online CPU on resume

2015-04-03T10:59:47+00:00

All CPUs leaving the first-online CPU are hotplugged out on suspend and
and cpufreq core stops managing them.

On resume, we need to call cpufreq_update_policy() for this CPU's policy
to make sure its frequency is in sync with cpufreq's cached value, as it
might have got updated by hardware during suspend/resume.

The policies are always added to the top of the policy-list. So, in
normal circumstances, CPU 0's policy will be the last one in the list.
And so the code checks for the last policy.

But there are cases where it will fail. Consider quad-core system, with
policy-per core. If CPU0 is hotplugged out and added back again, the
last policy will be on CPU1 :(

To fix this in a proper way, always look for the policy of the first
online CPU. That way we will be sure that we are calling
cpufreq_update_policy() for the only CPU that wasn't hotplugged out.

Cc: 3.15+  # 3.15+
Fixes: 2f0aea936360 ("cpufreq: suspend governors on system suspend/hibernate")
Reported-by: Saravana Kannan 
Signed-off-by: Viresh Kumar 
Acked-by: Saravana Kannan 
Signed-off-by: Rafael J. Wysocki

cpufreq: Create for_each_governor()

2015-02-03T22:28:01+00:00

To make code more readable and less error prone, lets create a helper macro for
iterating over all available governors.

Signed-off-by: Viresh Kumar 
Acked-by: Saravana Kannan 
Signed-off-by: Rafael J. Wysocki

cpufreq: Create for_each_policy()

2015-02-03T22:27:45+00:00

To make code more readable and less error prone, lets create a helper macro for
iterating over all active policies.

Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: Drop cpufreq_disabled() check from cpufreq_cpu_{get|put}()

2015-02-03T22:26:02+00:00

When cpufreq is disabled, the per-cpu variable would have been set to
NULL. Remove this unnecessary check.

[ Changelog from Saravana Kannan. ]

Signed-off-by: Viresh Kumar 
Acked-by: Saravana Kannan 
Signed-off-by: Rafael J. Wysocki

cpufreq: Set cpufreq_cpu_data to NULL before putting kobject

2015-02-02T23:59:29+00:00

In __cpufreq_remove_dev_finish(), per-cpu 'cpufreq_cpu_data' needs
to be cleared before calling kobject_put(&policy->kobj) and under
cpufreq_driver_lock. Otherwise, if someone else calls cpufreq_cpu_get()
in parallel with it, they can obtain a non-NULL policy from that after
kobject_put(&policy->kobj) was executed.

Consider this case:

Thread A				Thread B
cpufreq_cpu_get()
  acquire cpufreq_driver_lock
  read-per-cpu cpufreq_cpu_data
					kobject_put(&policy->kobj);
  kobject_get(&policy->kobj);
					...
					per_cpu(&cpufreq_cpu_data, cpu) = NULL

And this will result in a warning like this one:

 ------------[ cut here ]------------
 WARNING: CPU: 0 PID: 4 at include/linux/kref.h:47
 kobject_get+0x41/0x50()
 Modules linked in: acpi_cpufreq(+) nfsd auth_rpcgss nfs_acl
 lockd grace sunrpc xfs libcrc32c sd_mod ixgbe igb mdio ahci hwmon
 ...
 Call Trace:
  [] dump_stack+0x46/0x58
  [] warn_slowpath_common+0x81/0xa0
  [] warn_slowpath_null+0x1a/0x20
  [] kobject_get+0x41/0x50
  [] cpufreq_cpu_get+0x75/0xc0
  [] cpufreq_update_policy+0x2e/0x1f0
  [] ? up+0x32/0x50
  [] ? acpi_ns_get_node+0xcb/0xf2
  [] ? acpi_evaluate_object+0x22c/0x252
  [] ? acpi_get_handle+0x95/0xc0
  [] ? acpi_has_method+0x25/0x40
  [] acpi_processor_ppc_has_changed+0x77/0x82
  [] ? move_linked_works+0x66/0x90
  [] acpi_processor_notify+0x58/0xe7
  [] acpi_ev_notify_dispatch+0x44/0x5c
  [] acpi_os_execute_deferred+0x15/0x22
  [] process_one_work+0x160/0x410
  [] worker_thread+0x11b/0x520
  [] ? rescuer_thread+0x380/0x380
  [] kthread+0xe1/0x100
  [] ? kthread_create_on_node+0x1b0/0x1b0
  [] ret_from_fork+0x7c/0xb0
  [] ? kthread_create_on_node+0x1b0/0x1b0
 ---[ end trace 89e66eb9795efdf7 ]---

The actual code flow is as follows:

 Thread A: Workqueue: kacpi_notify

 acpi_processor_notify()
   acpi_processor_ppc_has_changed()
         cpufreq_update_policy()
           cpufreq_cpu_get()
             kobject_get()

 Thread B: xenbus_thread()

 xenbus_thread()
   msg->u.watch.handle->callback()
     handle_vcpu_hotplug_event()
       vcpu_hotplug()
         cpu_down()
           __cpu_notify(CPU_POST_DEAD..)
             cpufreq_cpu_callback()
               __cpufreq_remove_dev_finish()
                 cpufreq_policy_put_kobj()
                   kobject_put()

cpufreq_cpu_get() gets the policy from per-cpu variable cpufreq_cpu_data
under cpufreq_driver_lock, and once it gets a valid policy it expects it
to not be freed until cpufreq_cpu_put() is called.

But the race happens when another thread puts the kobject first and updates
cpufreq_cpu_data before or later. And so the first thread gets a valid policy
structure and before it does kobject_get() on it, the second one has already
done kobject_put().

Fix this by setting cpufreq_cpu_data to NULL before putting the kobject and that
too under locks.

Reported-by: Ethan Zhao 
Reported-by: Santosh Shilimkar 
Signed-off-by: Viresh Kumar 
Cc: 3.12+  # 3.12+
Signed-off-by: Rafael J. Wysocki

cpufreq: remove CPUFREQ_UPDATE_POLICY_CPU notifications

2015-01-23T22:06:44+00:00

CPUFREQ_UPDATE_POLICY_CPU notifications were used only from cpufreq-stats which
doesn't use it anymore. Remove them.

This also decrements values of other notification macros defined after
CPUFREQ_UPDATE_POLICY_CPU by 1 to remove gaps. Hopefully all users are using
macro's instead of direct numbers and so they wouldn't break as macro values are
changed now.

Reviewed-by: Prarit Bhargava 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: Remove (now) unused 'last_cpu' from struct cpufreq_policy

2015-01-23T22:06:44+00:00

'last_cpu' was used only from cpufreq-stats and isn't used anymore. Get rid of
it.

Reviewed-by: Prarit Bhargava 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: move some initialization stuff to cpufreq_policy_alloc()

2015-01-23T21:49:35+00:00

We need to initialize completion and work only on policy allocation and not
really on the policy restore side and so we better move this piece of code to
cpufreq_policy_alloc().

Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: check cpufreq_policy_list instead of scanning policies for all CPUs

2015-01-23T21:49:35+00:00

CPUFREQ_STICKY flag is set by drivers which don't want to get unregistered
even if cpufreq-core isn't able to initialize policy for any CPU.

When this flag isn't set, we try to unregister the driver. To find out
which CPUs are registered and which are not, we try to check per_cpu
cpufreq_cpu_data for all CPUs. Because we have a list of valid policies
available now, we better check if the list is empty or not instead of
the 'for' loop. That will be much more efficient.

Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: limit the scope of l_p_j variables

2015-01-23T21:49:34+00:00

These variables are just used within adjust_jiffies() and so must be
local to it. Also there is no need of a dummy routine for CONFIG_SMP
case as we can take care of all that with help of macros in the same
routine. It doesn't look that ugly.

Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki