75f5520077
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> [avajid@codeaurora.org: renamed to event lock and only used when CONFIG_QCOM_DEVFREQ_ICC is enabled] Signed-off-by: Amir Vajid <avajid@codeaurora.org> Signed-off-by: UtsavBalar1231 <utsavbalar1231@gmail.com> |
||
|---|---|---|
| .. | ||
| acpi | ||
| asm-generic | ||
| clocksource | ||
| crypto | ||
| drm | ||
| dt-bindings | ||
| keys | ||
| kvm | ||
| linux | ||
| math-emu | ||
| media | ||
| memory | ||
| microvisor | ||
| misc | ||
| net | ||
| pcmcia | ||
| ras | ||
| rdma | ||
| scsi | ||
| soc | ||
| sound | ||
| target | ||
| trace | ||
| uapi | ||
| vdso | ||
| video | ||
| vservices | ||
| xen | ||
| Kbuild | ||
| OWNERS | ||