1. 11 6月, 2015 2 次提交
    • V
      cpufreq: Initialize policy->kobj while allocating policy · 2fc3384d
      Viresh Kumar 提交于
      policy->kobj is required to be initialized once in the lifetime of a
      policy.  Currently we are initializing it from __cpufreq_add_dev() and
      that doesn't look to be the best place for doing so as we have to do
      this on special cases (like: !recover_policy).
      
      We can initialize it from a more obvious place cpufreq_policy_alloc()
      and that will make code look cleaner, specially the error handling part.
      
      The error handling part of __cpufreq_add_dev() was doing almost the same
      thing while recover_policy is true or false. Fix that as well by always
      calling cpufreq_policy_put_kobj() with an additional parameter to skip
      notification part of it.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2fc3384d
    • V
      cpufreq: Stop migrating sysfs files on hotplug · 87549141
      Viresh Kumar 提交于
      When we hot-unplug a cpu, we remove its sysfs cpufreq directory and if
      the outgoing cpu was the owner of policy->kobj earlier then we migrate
      the sysfs directory to under another online cpu.
      
      There are few disadvantages this brings:
      - Code Complexity
      - Slower hotplug/suspend/resume
      - sysfs file permissions are reset after all policy->cpus are offlined
      - CPUFreq stats history lost after all policy->cpus are offlined
      - Special management of sysfs stuff during suspend/resume
      
      To overcome these, this patch modifies the way sysfs directories are
      managed:
      - Select sysfs kobjects owner while initializing policy and don't change
        it during hotplugs. Track it with kobj_cpu created earlier.
      
      - Create symlinks for all related CPUs (can be offline) instead of
        affected CPUs on policy initialization and remove them only when the
        policy is freed.
      
      - Free policy structure only on the removal of cpufreq-driver and not
        during hotplug/suspend/resume, detected by checking 'struct
        subsys_interface *' (Valid only when called from
        subsys_interface_unregister() while unregistering driver).
      
      Apart from this, special care is taken to handle physical hoplug of CPUs
      as we wouldn't remove sysfs links or remove policies on logical
      hotplugs. Physical hotplug happens in the following sequence.
      
      Hot removal:
      - CPU is offlined first, ~ 'echo 0 >
        /sys/devices/system/cpu/cpuX/online'
      - Then its device is removed along with all sysfs files, cpufreq core
        notified with cpufreq_remove_dev() callback from subsys-interface..
      
      Hot addition:
      - First the device along with its sysfs files is added, cpufreq core
        notified with cpufreq_add_dev() callback from subsys-interface..
      - CPU is onlined, ~ 'echo 1 > /sys/devices/system/cpu/cpuX/online'
      
      We call the same routines with both hotplug and subsys callbacks, and we
      sense physical hotplug with cpu_offline() check in subsys callback. We
      can handle most of the stuff with regular hotplug callback paths and
      add/remove cpufreq sysfs links or free policy from subsys callbacks.
      Original-by: NSaravana Kannan <skannan@codeaurora.org>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      87549141
  2. 10 6月, 2015 1 次提交
  3. 23 5月, 2015 2 次提交
  4. 15 5月, 2015 6 次提交
  5. 08 5月, 2015 5 次提交
  6. 03 4月, 2015 1 次提交
    • V
      cpufreq: Schedule work for the first-online CPU on resume · c75de0ac
      Viresh Kumar 提交于
      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+ <stable@vger.kernel.org> # 3.15+
      Fixes: 2f0aea93 ("cpufreq: suspend governors on system suspend/hibernate")
      Reported-by: NSaravana Kannan <skannan@codeaurora.org>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: NSaravana Kannan <skannan@codeaurora.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c75de0ac
  7. 04 2月, 2015 3 次提交
  8. 03 2月, 2015 1 次提交
    • V
      cpufreq: Set cpufreq_cpu_data to NULL before putting kobject · 6ffae8c0
      Viresh Kumar 提交于
      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:
        [<ffffffff81661b14>] dump_stack+0x46/0x58
        [<ffffffff81072b61>] warn_slowpath_common+0x81/0xa0
        [<ffffffff81072c7a>] warn_slowpath_null+0x1a/0x20
        [<ffffffff812e16d1>] kobject_get+0x41/0x50
        [<ffffffff815262a5>] cpufreq_cpu_get+0x75/0xc0
        [<ffffffff81527c3e>] cpufreq_update_policy+0x2e/0x1f0
        [<ffffffff810b8cb2>] ? up+0x32/0x50
        [<ffffffff81381aa9>] ? acpi_ns_get_node+0xcb/0xf2
        [<ffffffff81381efd>] ? acpi_evaluate_object+0x22c/0x252
        [<ffffffff813824f6>] ? acpi_get_handle+0x95/0xc0
        [<ffffffff81360967>] ? acpi_has_method+0x25/0x40
        [<ffffffff81391e08>] acpi_processor_ppc_has_changed+0x77/0x82
        [<ffffffff81089566>] ? move_linked_works+0x66/0x90
        [<ffffffff8138e8ed>] acpi_processor_notify+0x58/0xe7
        [<ffffffff8137410c>] acpi_ev_notify_dispatch+0x44/0x5c
        [<ffffffff8135f293>] acpi_os_execute_deferred+0x15/0x22
        [<ffffffff8108c910>] process_one_work+0x160/0x410
        [<ffffffff8108d05b>] worker_thread+0x11b/0x520
        [<ffffffff8108cf40>] ? rescuer_thread+0x380/0x380
        [<ffffffff81092421>] kthread+0xe1/0x100
        [<ffffffff81092340>] ? kthread_create_on_node+0x1b0/0x1b0
        [<ffffffff81669ebc>] ret_from_fork+0x7c/0xb0
        [<ffffffff81092340>] ? 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: NEthan Zhao <ethan.zhao@oracle.com>
      Reported-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Cc: 3.12+ <stable@vger.kernel.org> # 3.12+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6ffae8c0
  9. 24 1月, 2015 18 次提交
  10. 20 12月, 2014 1 次提交
    • E
      cpufreq: fix a NULL pointer dereference in __cpufreq_governor() · cb57720b
      Ethan Zhao 提交于
      If ACPI _PPC changed notification happens before governor was initiated
      while kernel is booting, a NULL pointer dereference will be triggered:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
       IP: [<ffffffff81470453>] __cpufreq_governor+0x23/0x1e0
       PGD 0
       Oops: 0000 [#1] SMP
       ... ...
       RIP: 0010:[<ffffffff81470453>]  [<ffffffff81470453>]
       __cpufreq_governor+0x23/0x1e0
       RSP: 0018:ffff881fcfbcfbb8  EFLAGS: 00010286
       RAX: 0000000000000000 RBX: ffff881fd11b3980 RCX: ffff88407fc20000
       RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff881fd11b3980
       RBP: ffff881fcfbcfbd8 R08: 0000000000000000 R09: 000000000000000f
       R10: ffffffff818068d0 R11: 0000000000000043 R12: 0000000000000004
       R13: 0000000000000000 R14: ffffffff8196cae0 R15: 0000000000000000
       FS:  0000000000000000(0000) GS:ffff881fffc00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000000030 CR3: 00000000018ae000 CR4: 00000000000407f0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
       Process kworker/0:3 (pid: 750, threadinfo ffff881fcfbce000, task
       ffff881fcf556400)
       Stack:
        ffff881fffc17d00 ffff881fcfbcfc18 ffff881fd11b3980 0000000000000000
        ffff881fcfbcfc08 ffffffff81470d08 ffff881fd11b3980 0000000000000007
        ffff881fcfbcfc18 ffff881fffc17d00 ffff881fcfbcfd28 ffffffff81472e9a
       Call Trace:
        [<ffffffff81470d08>] __cpufreq_set_policy+0x1b8/0x2e0
        [<ffffffff81472e9a>] cpufreq_update_policy+0xca/0x150
        [<ffffffff81472f20>] ? cpufreq_update_policy+0x150/0x150
        [<ffffffff81324a96>] acpi_processor_ppc_has_changed+0x71/0x7b
        [<ffffffff81320bcd>] acpi_processor_notify+0x55/0x115
        [<ffffffff812f9c29>] acpi_device_notify+0x19/0x1b
        [<ffffffff813084ca>] acpi_ev_notify_dispatch+0x41/0x5f
        [<ffffffff812f64a4>] acpi_os_execute_deferred+0x27/0x34
      
      The root cause is a race conditon -- cpufreq core and acpi-cpufreq driver
      were initiated, but cpufreq_governor wasn't and _PPC changed notification
      happened, __cpufreq_governor() was called within acpi_os_execute_deferred
      kernel thread context.
      
      To fix this panic issue, add pointer checking code in __cpufreq_governor()
      before pointer policy->governor is to be dereferenced.
      Signed-off-by: NEthan Zhao <ethan.zhao@oracle.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      cb57720b
新手
引导
客服 返回
顶部