linux-kernel - [PATCH] x86: Fix thermal throttling reporting after kexec

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: <1444681922-8644-1-git-send-email-andi@firstfloor.org>
Date:	Mon, 12 Oct 2015 13:32:02 -0700
From:	Andi Kleen <andi@...stfloor.org>
To:	tony.luck@...el.com
Cc:	bp@...en8.de, tglx@...utronix.de, linux-kernel@...r.kernel.org,
	Andi Kleen <ak@...ux.intel.com>
Subject: [PATCH] x86: Fix thermal throttling reporting after kexec

From: Andi Kleen <ak@...ux.intel.com>

The per CPU thermal vector init code checks if the thermal
vector is already installed and complains and bails out if
it is.

This happens after kexec, as kernel shut down does
not clear the thermal vector APIC register.

This causes two problems:

So we always do not fully initialize thermal reports
after kexec. The CPU is still likely initialized,
as the previous kernel should have done it. But
we don't set up the software pointer to the thermal
vector, so reporting may end up with a unknown thermal
interrupt message.

Also it complains for every logical CPU, even though the
value is actually derived from BP only.

The problem is that we end up with one message per CPU,
so on larger systems it becomes very noisy and messes up
the otherwise nicely formatted CPU bootup numbers in
the kernel log.

Just remove the check. I checked the code and there's
no valid code paths where the thermal init code for a CPU
could be called multiple times.

Why the kernel does not clean up this value on shutdown:

The thermal monitoring is controlled per logical CPU thread.
Normal shutdown code is just running on one CPU.
To disable it we would need a broadcast NMI to all CPUs
on shut down. That's overkill for this. So we just
ignore it after kexec.

v2: Updated commit log to discuss why the value is not
cleaned up on shutdown.
Signed-off-by: Andi Kleen <ak@...ux.intel.com>
---
 arch/x86/kernel/cpu/mcheck/therm_throt.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/therm_throt.c b/arch/x86/kernel/cpu/mcheck/therm_throt.c
index 1af51b1..2c5aaf8 100644
--- a/arch/x86/kernel/cpu/mcheck/therm_throt.c
+++ b/arch/x86/kernel/cpu/mcheck/therm_throt.c
@@ -503,14 +503,6 @@ void intel_init_thermal(struct cpuinfo_x86 *c)
 		return;
 	}

-	/* Check whether a vector already exists */
-	if (h & APIC_VECTOR_MASK) {
-		printk(KERN_DEBUG
-		       "CPU%d: Thermal LVT vector (%#x) already installed\n",
-		       cpu, (h & APIC_VECTOR_MASK));
-		return;
-	}
-
 	/* early Pentium M models use different method for enabling TM2 */
 	if (cpu_has(c, X86_FEATURE_TM2)) {
 		if (c->x86 == 6 && (c->x86_model == 9 || c->x86_model == 13)) {
-- 
2.4.3

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