]> www.infradead.org Git - nvme.git/commit
cpufreq/sched: Explicitly synchronize limits_changed flag handling
authorRafael J. Wysocki <rafael.j.wysocki@intel.com>
Tue, 15 Apr 2025 09:59:15 +0000 (11:59 +0200)
committerRafael J. Wysocki <rafael.j.wysocki@intel.com>
Thu, 17 Apr 2025 15:54:44 +0000 (17:54 +0200)
commit79443a7e9da3c9f68290a8653837e23aba0fa89f
tree1aa607fb5963199b821d84aa05db6abb012a9cc4
parentcfde542df7dd51d26cf667f4af497878ddffd85a
cpufreq/sched: Explicitly synchronize limits_changed flag handling

The handling of the limits_changed flag in struct sugov_policy needs to
be explicitly synchronized to ensure that cpufreq policy limits updates
will not be missed in some cases.

Without that synchronization it is theoretically possible that
the limits_changed update in sugov_should_update_freq() will be
reordered with respect to the reads of the policy limits in
cpufreq_driver_resolve_freq() and in that case, if the limits_changed
update in sugov_limits() clobbers the one in sugov_should_update_freq(),
the new policy limits may not take effect for a long time.

Likewise, the limits_changed update in sugov_limits() may theoretically
get reordered with respect to the updates of the policy limits in
cpufreq_set_policy() and if sugov_should_update_freq() runs between
them, the policy limits change may be missed.

To ensure that the above situations will not take place, add memory
barriers preventing the reordering in question from taking place and
add READ_ONCE() and WRITE_ONCE() annotations around all of the
limits_changed flag updates to prevent the compiler from messing up
with that code.

Fixes: 600f5badb78c ("cpufreq: schedutil: Don't skip freq update when limits change")
Cc: 5.3+ <stable@vger.kernel.org> # 5.3+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Christian Loehle <christian.loehle@arm.com>
Link: https://patch.msgid.link/3376719.44csPzL39Z@rjwysocki.net
kernel/sched/cpufreq_schedutil.c