• B
    cpufreq: fix garbage kobjects on errors during suspend/resume · 2167e239
    Bjørn Mork 提交于
    This is effectively a revert of commit 5302c3fb ("cpufreq: Perform
    light-weight init/teardown during suspend/resume"), which enabled
    suspend/resume optimizations leaving the sysfs files in place.
    
    Errors during suspend/resume are not handled properly, leaving
    dead sysfs attributes in case of failures.  There are are number of
    functions with special code for the "frozen" case, and all these
    need to also have special error handling.
    
    The problem is easy to demonstrate by making cpufreq_driver->init()
    or cpufreq_driver->get() fail during resume.
    
    The code is too complex for a simple fix, with split code paths
    in multiple blocks within a number of functions.  It is therefore
    best to revert the patch enabling this code until the error handling
    is in place.
    
    Examples of problems resulting from resume errors:
    
    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
    
    The failure to restore cpufreq devices on cancelled hibernation is
    not a new bug. It is caused by the ACPI _PPC call failing unless the
    hibernate is completed. This makes the acpi_cpufreq driver fail its
    init.
    
    Previously, the cpufreq device could be restored by offlining the
    cpu temporarily.  And as a complete hibernation cycle would do this,
    it would be automatically restored most of the time.  But after
    commit 5302c3fb the leftover sysfs attributes will block any
    device add action.  Therefore offlining and onlining CPU 1 will no
    longer restore the cpufreq object, and a complete suspend/resume
    cycle will replace it with garbage.
    
    Fixes: 5302c3fb ("cpufreq: Perform light-weight init/teardown during suspend/resume")
    Cc: 3.12+ <stable@vger.kernel.org> # 3.12+
    Signed-off-by: NBjørn Mork <bjorn@mork.no>
    Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
    2167e239
cpufreq.c 56.2 KB