• V
    cpufreq: governor: New sysfs show/store callbacks for governor tunables · c4435630
    Viresh Kumar 提交于
    The ondemand and conservative governors use the global-attr or freq-attr
    structures to represent sysfs attributes corresponding to their tunables
    (which of them is actually used depends on whether or not different
    policy objects can use the same governor with different tunables at the
    same time and, consequently, on where those attributes are located in
    sysfs).
    
    Unfortunately, in the freq-attr case, the standard cpufreq show/store
    sysfs attribute callbacks are applied to the governor tunable attributes
    and they always acquire the policy->rwsem lock before carrying out the
    operation.  That may lead to an ABBA deadlock if governor tunable
    attributes are removed under policy->rwsem while one of them is being
    accessed concurrently (if sysfs attributes removal wins the race, it
    will wait for the access to complete with policy->rwsem held while the
    attribute callback will block on policy->rwsem indefinitely).
    
    We attempted to address this issue by dropping policy->rwsem around
    governor tunable attributes removal (that is, around invocations of the
    ->governor callback with the event arg equal to CPUFREQ_GOV_POLICY_EXIT)
    in cpufreq_set_policy(), but that opened up race conditions that had not
    been possible with policy->rwsem held all the time.  Therefore
    policy->rwsem cannot be dropped in cpufreq_set_policy() at any point,
    but the deadlock situation described above must be avoided too.
    
    To that end, use the observation that in principle governor tunables may
    be represented by the same data type regardless of whether the governor
    is system-wide or per-policy and introduce a new structure, struct
    governor_attr, for representing them and new corresponding macros for
    creating show/store sysfs callbacks for them.  Also make their parent
    kobject use a new kobject type whose default show/store callbacks are
    not related to the standard core cpufreq ones in any way (and they don't
    acquire policy->rwsem in particular).
    Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
    Tested-by: NJuri Lelli <juri.lelli@arm.com>
    Tested-by: NShilpasri G Bhat <shilpa.bhat@linux.vnet.ibm.com>
    [ rjw: Subject & changelog + rebase ]
    Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
    c4435630
cpufreq_ondemand.c 17.2 KB