linux-kernel - Re: [PATCH] PM / devfreq: Fix atomicity violation in devfreq_update

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CANgpojVi8q9kaUsOY9-GGGbKbUe9H_eghqPbDEH1=U=ZZGkfwg@mail.gmail.com>
Date: Mon, 30 Sep 2024 17:53:09 +0800
From: Qiu-ji Chen <chenqiuji666@...il.com>
To: myungjoo.ham@...sung.com, kyungmin.park@...sung.com, cw00.choi@...sung.com
Cc: linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	baijiaju1990@...il.com, stable@...r.kernel.org
Subject: Re: [PATCH] PM / devfreq: Fix atomicity violation in devfreq_update_interval()

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