cpufreq: remove sysfs files for CPUs which failed to come back after resume
There are cases where cpufreq_add_dev() may fail for some CPUs
during system resume. With the current code we will still have
sysfs cpufreq files for those CPUs and struct cpufreq_policy
would be already freed for them. Hence any operation on those
sysfs files would result in kernel warnings.
Example of problems resulting from resume errors (from Bjørn Mork):
WARNING: CPU: 0 PID: 6055 at fs/sysfs/file.c:343 sysfs_open_file+0x77/0x212()
missing sysfs attribute operations for kobject: (null)
Modules linked in: [stripped as irrelevant]
CPU: 0 PID: 6055 Comm: grep Tainted: G D 3.13.0-rc2 #153
Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
0000000000000009 ffff8802327ebb78 ffffffff81380b0e 0000000000000006
ffff8802327ebbc8 ffff8802327ebbb8 ffffffff81038635 0000000000000000
ffffffff811823c7 ffff88021a19e688 ffff88021a19e688 ffff8802302f9310
Call Trace:
[<
ffffffff81380b0e>] dump_stack+0x55/0x76
[<
ffffffff81038635>] warn_slowpath_common+0x7c/0x96
[<
ffffffff811823c7>] ? sysfs_open_file+0x77/0x212
[<
ffffffff810386e3>] warn_slowpath_fmt+0x41/0x43
[<
ffffffff81182dec>] ? sysfs_get_active+0x6b/0x82
[<
ffffffff81182382>] ? sysfs_open_file+0x32/0x212
[<
ffffffff811823c7>] sysfs_open_file+0x77/0x212
[<
ffffffff81182350>] ? sysfs_schedule_callback+0x1ac/0x1ac
[<
ffffffff81122562>] do_dentry_open+0x17c/0x257
[<
ffffffff8112267e>] finish_open+0x41/0x4f
[<
ffffffff81130225>] do_last+0x80c/0x9ba
[<
ffffffff8112dbbd>] ? inode_permission+0x40/0x42
[<
ffffffff81130606>] path_openat+0x233/0x4a1
[<
ffffffff81130b7e>] do_filp_open+0x35/0x85
[<
ffffffff8113b787>] ? __alloc_fd+0x172/0x184
[<
ffffffff811232ea>] do_sys_open+0x6b/0xfa
[<
ffffffff811233a7>] SyS_openat+0xf/0x11
[<
ffffffff8138c812>] system_call_fastpath+0x16/0x1b
To fix this, remove those sysfs files or put the associated kobject
in case of such errors. Also, to make it simple, remove the cpufreq
sysfs links from all the CPUs (except for the policy->cpu) during
suspend, as that operation won't result in a loss of sysfs file
permissions and we can create those links during resume just fine.
Fixes:
5302c3fb2e62 ("cpufreq: Perform light-weight init/teardown during suspend/resume")
Reported-and-tested-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: 3.12+ <stable@vger.kernel.org> # 3.12+
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>