linux-kernel - Re: [PATCH 1/2] x86, mce, therm_throt: Optimize logging of thermal throttle messages

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: <20191018194503.GF17053@zn.tnic>
Date:   Fri, 18 Oct 2019 21:45:03 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     "Luck, Tony" <tony.luck@...el.com>
Cc:     Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "hpa@...or.com" <hpa@...or.com>,
        "bberg@...hat.com" <bberg@...hat.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "hdegoede@...hat.com" <hdegoede@...hat.com>,
        "ckellner@...hat.com" <ckellner@...hat.com>
Subject: Re: [PATCH 1/2] x86, mce, therm_throt: Optimize logging of thermal
 throttle messages

On Fri, Oct 18, 2019 at 11:02:57AM -0700, Luck, Tony wrote:
> So what should we do next?

I was simply keying off this statement of yours:

"Depending on what we end up with from Srinivas ... we may want to
reconsider the severity."

and I don't think that having KERN_CRIT severity for those messages
makes any sense. That's why I was hinting at us organizing and defining
our handling of thermal interrupt events properly so that we handle
those things correctly and not have people look at dmesg.

> I don't think there is much by way of actions that the kernel should
> take. While we could stop scheduling processes, the h/w and f/w have
> better tools to reduce frequency, inject idle cycles, speed up fans,
> etc. If you do have ideas ... then please share.

See above. All resulted from me stating that KERN_CRIT messages or any
type of messages in dmesg as a result of hitting thermal limits are
useless. If we wanna handle those properly, then we need to do something
else.

> Proposal on the table is the algoritm embodied in Srinivas'
> patch (which originated from Alan Cox).

I think we agree on doing the dynamic threshold determination, no?

If, as Srinivas points out in another mail, the purpose of those
messages is when one wants to examine what happened, then fine. If we
must do more, then see above.

Does that make more sense?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette