diff options
author | Daniel Lezcano <daniel.lezcano@linaro.org> | 2024-10-24 12:23:03 +0200 |
---|---|---|
committer | Rafael J. Wysocki <rafael.j.wysocki@intel.com> | 2024-10-24 15:00:18 +0200 |
commit | 54219ee4eaeb356e0c8e0a6609dc6b5c21e2170a (patch) | |
tree | 7299c06813f5808904f004b1925b3551d77f1582 /tools | |
parent | 41b89dba7c5dd0a071c52aa2f8c87c507e30dfbe (diff) | |
download | lwn-54219ee4eaeb356e0c8e0a6609dc6b5c21e2170a.tar.gz lwn-54219ee4eaeb356e0c8e0a6609dc6b5c21e2170a.zip |
thermal: thresholds: Fix thermal lock annotation issue
When the thermal zone is unregistered (thermal sensor module being
unloaded), no lock is held when flushing the thresholds. That results
in a WARN when the lockdep validation is set in the kernel config.
This has been reported by syzbot.
As the thermal zone is in the process of being destroyed, there is no
need to send a notification about purging the thresholds to the
userspace as this one will receive a thermal zone deletion
notification which imply the deletion of all the associated resources
like the trip points or the user thresholds.
Split the function thermal_thresholds_flush() into a lockless one
without notification and its call with the lock annotation followed
with the thresholds flushing notification.
Please note this scenario is unlikely to happen, as the sensor drivers
are usually compiled-in in order to have the thermal framework to be
able to kick in at boot time if needed.
Fixes: 445936f9e258 ("thermal: core: Add user thresholds support")
Link: https://lore.kernel.org/all/67124175.050a0220.10f4f4.0012.GAE@google.com
Reported-by: syzbot+f24dd060c1911fe54c85@syzkaller.appspotmail.com
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://patch.msgid.link/20241024102303.1086147-1-daniel.lezcano@linaro.org
[ rjw: Subject edit, added Fixes tag ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Diffstat (limited to 'tools')
0 files changed, 0 insertions, 0 deletions