linux-kernel - Adding hysteresis to thermal_zone_device_update in drivers/thermal/thermal

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>] [day] [month] [year] [list]

Message-ID: <CAPQV+nMqJDOyfvg+naQZaUUgqfR0xCnbcxUxdEoXmwJhkmN7Tg@mail.gmail.com>
Date:	Thu, 12 Apr 2012 14:00:47 -0400
From:	Jonathan Kliegman <kliegs@...omium.org>
To:	linux-kernel@...r.kernel.org
Subject: Adding hysteresis to thermal_zone_device_update in drivers/thermal/thermal_sys.c

I was looking at thermal_zone_device_update in
drivers/thermal/thermal_sys.c to add hysteresis for turning on
non-critical fans.  While doing this I noticed that when a fan changed
state as a result of this function, it would trigger the function
being reentered again.  The function itself is protected by a
mutex_lock call so its safe to do so.  However this means that logic
such as "check if temperature exceeded trips value for this call and
previous call" doesn't work as the two calls can be occurring at the
same time.

The actual reason for reentering is that thermal_zone_device_update in
addition to being called on a timer, will also be called from
acpi_thermal_notify which gets triggered when a fan transitions state
to on or off.  So if thermal_zone_device_update decides to turn a fan
on or off, it will immediately be called again.

What is the right way to fix this and add the ability to check that
the temperature has maintained a value over the trips value?  Should I
look at changing the callback path for fan change to not call
thermal_zone_device_update if its what triggered the fan change?  Or
would it be better to implement more complicated checks on the
temperature values to take into account the time it first passed the
trips threshold rather than just checking that a previous check saw it
over the threshold?

-Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/