PM / devfreq: Introduce a sysfs lock
Currently, concurrent writes to sysfs entries leave the possibility for
race conditions within the devfreq framework. For example, concurrently
executing max_freq_store and governor_store can result in attempting to
perform an update_devfreq() before the new governor's start handler can be
executed.
A more concrete case is a race between polling_interval_store and
governor_store. Because no lock is used after calling into the event
handler of the old governor and there's nothing preventing work from being
queued after the monitor is stopped, it's possible to accidentally cause
delayed work to be queued on the governor being switched to. This can be
seen if you create two threads, one which changes a device's governor
between simple_ondemand and performance, and one which changes its polling
interval between 45 and 50.
All of these races can be addressed with the introduction of a lock that
prevents sysfs operations from interleaving in this fashion.
Change-Id: Ia6887dcb2d69dc2576837a6c09fed55a28943abc
Signed-off-by: Jonathan Avila <avilaj@codeaurora.org>
2 files changed