linux-kernel - Requesting inclusion of 26bb0e9a in linux-3.14.y

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

Message-ID: <55AE2FD5.3000207@free.fr>
Date:	Tue, 21 Jul 2015 13:41:09 +0200
From:	Mason <slash.tmp@...e.fr>
To:	stable@...r.kernel.org
CC:	LKML <linux-kernel@...r.kernel.org>,
	Lukasz Majewski <l.majewski@...sung.com>,
	Zhang Rui <rui.zhang@...el.com>
Subject: Requesting inclusion of 26bb0e9a in linux-3.14.y

Hello,

This is my first time requesting inclusion of a patch, please
point out any breach of protocol.

I'm using linux-3.14.y and I've run into a bug fixed in later
kernel versions:

commit 26bb0e9a1a938ec98ee07aa76533f1a711fba706
Author: Lukasz Majewski <l.majewski@...sung.com>
Date:   Wed Sep 24 10:27:10 2014 +0200

    thermal: step_wise: fix: Prevent from binary overflow when trend is dropping
    
    It turns out that some boards can have instance->lower greater than 0 and
    when thermal trend is dropping it results with next_target equal to -1.
    
    Since the next_target is defined as unsigned long it is interpreted as
    0xFFFFFFFF and larger than instance->upper.
    As a result the next_target is set to instance->upper which ramps up to
    maximal cooling device target when the temperature is steadily decreasing.
    
    Signed-off-by: Lukasz Majewski <l.majewski@...sung.com>
    Signed-off-by: Zhang Rui <rui.zhang@...el.com>

diff --git a/drivers/thermal/step_wise.c b/drivers/thermal/step_wise.c
index f251521baaa2..6705a0d746b3 100644
--- a/drivers/thermal/step_wise.c
+++ b/drivers/thermal/step_wise.c
@@ -76,7 +76,7 @@ static unsigned long get_target_state(struct thermal_instance *instance,
                        next_target = instance->upper;
                break;
        case THERMAL_TREND_DROPPING:
-               if (cur_state == instance->lower) {
+               if (cur_state <= instance->lower) {
                        if (!throttle)
                                next_target = THERMAL_NO_TARGET;
                } else {




Here's the debug output on my board:

[   21.301211] thermal thermal_zone0: last_temperature=0, current_temperature=51000
[   21.308803] thermal thermal_zone0: Trip0[type=1,temp=70000]:trend=1,throttle=0
[   21.316248] thermal cooling_device0: cur_state=0
[   21.320957] thermal cooling_device0: old_target=-1, target=-1
[   21.326755] thermal cooling_device0: zone0->target=4294967295
[   21.332544] thermal cooling_device0: set to state 0

[   34.349747] thermal thermal_zone0: last_temperature=51000, current_temperature=46000
[   34.357830] thermal thermal_zone0: Trip0[type=1,temp=70000]:trend=2,throttle=0
[   34.365254] thermal cooling_device0: cur_state=0
[   34.369989] thermal cooling_device0: old_target=-1, target=4
[   34.375740] thermal cooling_device0: zone0->target=4
[   34.380867] thermal cooling_device0: set to state 4

Bug: raising the cooling state, despite the temperature dropping.

The .bind() call was

  thermal_zone_bind_cooling_device(tz, 0, cdev, 4, 1);

(The intent being that, once the system is above the trip temp,
at least a little bit of cooling should be applied, always.)

cur_state = 0 is not equal to lower_state = 1

AFAICT, Lukasz's patch fixes that issue.

Regards.
--
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/