On 22-02-16, 14:14, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki <[email protected]> > > There is a scenario that may lead to undesired results in > dbs_update_util_handler(). Namely, if two CPUs sharing a policy > enter the funtion at the same time, pass the sample delay check > and then one of them is stalled until dbs_work_handler() (queued > up by the other CPU) clears the work counter, it may update the > work counter and queue up another work item prematurely. > > To prevent that from happening, use the observation that the CPU > queuing up a work item in dbs_update_util_handler() updates the > last sample time. This means that if another CPU was stalling after > passing the sample delay check and now successfully updated the work > counter as a result of the race described above, it will see the new > value of the last sample time which is different from what it used in > the sample delay check before. If that happens, the sample delay > check passed previously is not valid any more, so the CPU should not > continue. > > Fixes: f17cbb53783c (cpufreq: governor: Avoid atomic operations in hot paths) > Signed-off-by: Rafael J. Wysocki <[email protected]> > --- > > Changes from v1: > - Typo in the changelog fixed. > - READ_ONCE() used instead of ACCESS_ONCE(). > - If the race is detected, return instead of looping.
Acked-by: Viresh Kumar <[email protected]> -- viresh
