linux-kernel - Re: [PATCH v8 03/10] thermal: Use generic HW-protection shutdown API

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

Message-ID: <13ede9c1a755300f90c0e2f454cb12ee7a89e3ac.camel@fi.rohmeurope.com>
Date:   Thu, 22 Apr 2021 09:27:37 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>
CC:     "josef@...icpanda.com" <josef@...icpanda.com>,
        "keescook@...omium.org" <keescook@...omium.org>,
        "rppt@...nel.org" <rppt@...nel.org>,
        "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
        "pmladek@...e.com" <pmladek@...e.com>,
        linux-power <linux-power@...rohmeurope.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "bjorn.andersson@...aro.org" <bjorn.andersson@...aro.org>,
        "rui.zhang@...el.com" <rui.zhang@...el.com>,
        "linux-renesas-soc@...r.kernel.org" 
        <linux-renesas-soc@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "linux@...ck-us.net" <linux@...ck-us.net>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "kai.heng.feng@...onical.com" <kai.heng.feng@...onical.com>,
        "mcroce@...rosoft.com" <mcroce@...rosoft.com>,
        "amitk@...nel.org" <amitk@...nel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "andy.shevchenko@...il.com" <andy.shevchenko@...il.com>,
        "agross@...nel.org" <agross@...nel.org>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "rafael.j.wysocki@...el.com" <rafael.j.wysocki@...el.com>
Subject: Re: [PATCH v8 03/10] thermal: Use generic HW-protection shutdown API

Hi Daniel, all,

On Thu, 2021-04-22 at 10:10 +0200, Daniel Lezcano wrote:
> On 19/04/2021 13:49, Matti Vaittinen wrote:
> > The hardware shutdown function was exported from kernel/reboot for
> > other subsystems to use. Logic is copied from the thermal_core. The
> > protection mutex is replaced by an atomic_t to allow calls also
> > from
> > an IRQ context.
> > 
> > Use the exported API instead of implementing own just for the
> > thermal_core.
> 
> Can you update the documentation:
> 
> Documentation/driver-api/thermal/sysfs-api.rst
> 
> 5. thermal_emergency_poweroff
> 

I can. Problem is what to put there.

I like the fact that logic of an emergency shut-down is described. Yet,
describing in thermal_core documentation what an API hosted in
kernel/reboot does sounds like a call for documentation which may not
match implementation in the long run.

I drafted following:
diff --git a/Documentation/driver-api/thermal/sysfs-api.rst
b/Documentation/driver-api/thermal/sysfs-api.rst
index 29fdd817ddb0..a10bfe6e7293 100644
--- a/Documentation/driver-api/thermal/sysfs-api.rst
+++ b/Documentation/driver-api/thermal/sysfs-api.rst
@@ -751,20 +751,14 @@ possible.
 =============================
 
 On an event of critical trip temperature crossing. Thermal framework
-allows the system to shutdown gracefully by calling
orderly_poweroff().
-In the event of a failure of orderly_poweroff() to shut down the
system
-we are in danger of keeping the system alive at undesirably high
-temperatures. To mitigate this high risk scenario we program a work
-queue to fire after a pre-determined number of seconds to start
-an emergency shutdown of the device using the kernel_power_off()
-function. In case kernel_power_off() fails then finally
-emergency_restart() is called in the worst case.
+shuts down the system by calling hw_protection_shutdown(). The
+hw_protection_shutdown() first attempts to perform an orderly shutdown
+but accepts a delay after which it proceeds doing a forced power-off
+or an emergency_restart.
 
 The delay should be carefully profiled so as to give adequate time for
-orderly_poweroff(). In case of failure of an orderly_poweroff() the
-emergency poweroff kicks in after the delay has elapsed and shuts down
-the system.
+orderly poweroff.
 
-If set to 0 emergency poweroff will not be supported. So a carefully
-profiled non-zero positive value is a must for emergency poweroff to
be
-triggered.
+If the delay is set to 0 emergency poweroff will not be supported. So
a
+carefully profiled non-zero positive value is a must for emergency
+poweroff to be triggered.


but I'm not sure what to think about it.

Opinions/suggestions?

Best Regards
	Matti Vaittinen