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: <20191018203832.GA25033@agluck-desk2.amr.corp.intel.com>
Date:   Fri, 18 Oct 2019 13:38:32 -0700
From:   "Luck, Tony" <tony.luck@...el.com>
To:     Borislav Petkov <bp@...en8.de>
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 09:45:03PM +0200, Borislav Petkov wrote:
> 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.

Sorry to have caused confusion. The thoughts behind that statement
are that we currently have an issue with too many noisy high severity
messages.  The interim solution we are going with is to downgrade
the severity.  But if we apply a time based filter to remove most of
the noise by not printing at all, maybe what we have left is a very
small number of high severity messages.

But that's completely up for debate.

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

I agree it is a good thing to look at. I'm not so sure we will find
a good enough method that works all the way from tablet to server,
so we might end up with "#define MAX_THERM_TIME 8000" ... but some
study of options would either turn up a good heuristic, or provide
evidence for why that is either hard, or no better than a constant.

> Does that make more sense?

Yes. Thanks for the clarifications.

-Tony