linux-kernel - Re: [PATCH v5] drivers: thermal: clear all mitigation when thermal zone is disabled

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

Message-ID: <c02d28ce-bef4-0b71-e90a-991ef4fae9d3@quicinc.com>
Date:   Tue, 15 Feb 2022 01:30:04 +0530
From:   Manaf Meethalavalappu Pallikunhi <quic_manafm@...cinc.com>
To:     Lukasz Luba <lukasz.luba@....com>
CC:     <linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        Zhang Rui <rui.zhang@...el.com>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        "Amit Kucheria" <amitk@...nel.org>,
        Daniel Lezcano <daniel.lezcano@...aro.org>
Subject: Re: [PATCH v5] drivers: thermal: clear all mitigation when thermal
 zone is disabled


On 1/31/2022 12:55 PM, Lukasz Luba wrote:
> Hi Manaf,
>
> On 1/27/22 6:11 PM, Manaf Meethalavalappu Pallikunhi wrote:
>> Whenever a thermal zone is in trip violated state, there is a chance
>> that the same thermal zone mode can be disabled either via
>> thermal core API or via thermal zone sysfs. Once it is disabled,
>> the framework bails out any re-evaluation of thermal zone. It leads
>> to a case where if it is already in mitigation state, it will stay
>> the same state forever.
>>
>> To avoid above mentioned issue, add support to bind/unbind
>> governor from thermal zone during thermal zone mode change request
>> and clear all existing throttling in governor unbind_from_tz()
>> callback.
>
> I have one use case:
> This would be a bit dangerous, e.g. to switch governors while there is a
> high temperature. Although, sounds reasonable to left a 'default' state
> for a next governor.
>
I believe only way to change the governror via userspace at runtime.

Just re-evaluate thermal zone  (thermal_zone_device_update) immediately  
after

thermal_zone_device_set_policy()  in same policy_store() context, isn't 
it good enough ?

Not sure how a "default" state  can be reverted once governor change is 
done.

Re-evaluating thermal zone doesn't guarantee that it will recover previous

set default state for all governors, right ?

>>
>> Suggested-by: Daniel Lezcano <daniel.lezcano@...aro.org>
>> Signed-off-by: Manaf Meethalavalappu Pallikunhi 
>> <quic_manafm@...cinc.com>
>> ---
>>   drivers/thermal/gov_power_allocator.c |  3 +++
>>   drivers/thermal/gov_step_wise.c       | 26 ++++++++++++++++++++++++++
>>   drivers/thermal/thermal_core.c        | 31 
>> +++++++++++++++++++++++++++----
>>   3 files changed, 56 insertions(+), 4 deletions(-)
>
> Why only two governors need that change and not all?
> Because they don't have 'bind/unbind' callbacks, then maybe we should
> change that as well to make it consistent?
I will update other governors as well in v6
>
> Regards,
> Lukasz