The atomicity violation occurs when the variables cur_delay and new_delay are defined. Imagine a scenario where, while defining cur_delay and new_delay, the values stored in devfreq->profile->polling_ms and the delay variable change. After acquiring the mutex_lock and entering the critical section, due to possible concurrent modifications, cur_delay and new_delay may no longer represent the correct values. Subsequent usage, such as if (cur_delay > new_delay), could cause the program to run incorrectly, resulting in inconsistencies.
To address this issue, it is recommended to acquire a lock in advance, ensuring that devfreq->profile->polling_ms and delay are protected by the lock when being read. This will help ensure the consistency of the program.
This possible bug is found by an experimental static analysis tool developed by our team. This tool analyzes the locking APIs to extract function pairs that can be concurrently executed, and then analyzes the instructions in the paired functions to identify possible concurrency bugs including data races and atomicity violations.
Fixes: 7e6fdd4bad03 ("PM / devfreq: Core updates to support devices which can idle") Cc: stable@vger.kernel.org Signed-off-by: Qiu-ji Chen chenqiuji666@gmail.com --- drivers/devfreq/devfreq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c index 98657d3b9435..9634739fc9cb 100644 --- a/drivers/devfreq/devfreq.c +++ b/drivers/devfreq/devfreq.c @@ -616,10 +616,10 @@ EXPORT_SYMBOL(devfreq_monitor_resume); */ void devfreq_update_interval(struct devfreq *devfreq, unsigned int *delay) { + mutex_lock(&devfreq->lock); unsigned int cur_delay = devfreq->profile->polling_ms; unsigned int new_delay = *delay;
- mutex_lock(&devfreq->lock); devfreq->profile->polling_ms = new_delay;
if (IS_SUPPORTED_FLAG(devfreq->governor->flags, IRQ_DRIVEN))
Hi MyungJoo Ham,
Based on our understanding of the code, the variable cur_delay stores the old value of devfreq->profile->polling_ms. We also agree that reading from *delay does not need to be protected by the lock. The reason we moved both definitions inside the lock is to maintain the original order of the code. We apologize for the misunderstanding this may have caused.
If the read of devfreq->profile->polling_ms is not protected by the lock, the cur_delay that enters the critical section would not store the actual old value of devfreq->profile->polling_ms, which would affect the subsequent checks like if (!cur_delay) and if (cur_delay > new_delay), potentially causing the driver to perform incorrect operations.
We believe that moving the read of devfreq->profile->polling_ms inside the lock is beneficial as it ensures that cur_delay stores the true old value of devfreq->profile->polling_ms, ensuring the correctness of the later checks.
As for acquiring the lock in the caller, we believe that this is not suitable in this case because it may require introducing a new lock. Furthermore, the function takes a struct devfreq *devfreq as a parameter and accesses devfreq->profile->polling_ms, so holding devfreq->lock prevents devfreq->profile->polling_ms from being modified. Protecting the read operation with devfreq->lock seems natural and ensures that the retrieved value is the real old value of devfreq->profile->polling_ms, which we believe is effective.
Thank you for your response, and we welcome further discussion.
Qiu-ji Chen
linux-stable-mirror@lists.linaro.org
-
Qiu-ji Chen