linux-kernel - Re: [stable] [patch 31/32] x86_64: fix boot hang due to nmi watchdog init code

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20061211183323.GC1397@sequoia.sous-sol.org>
Date:	Mon, 11 Dec 2006 10:33:23 -0800
From:	Chris Wright <chrisw@...s-sol.org>
To:	linux-kernel@...r.kernel.org, stable@...nel.org, ak@....de
Cc:	akpm@...l.org, "Theodore Ts'o" <tytso@....edu>,
	Zwane Mwaikambo <zwane@....linux.org.uk>,
	Justin Forbes <jmforbes@...uxtx.org>, torvalds@...l.org,
	Chris Wedgwood <reviews@...cw.f00f.org>, shai@...lex86.org,
	Randy Dunlap <rdunlap@...otime.net>,
	Michael Krufky <mkrufky@...uxtv.org>,
	Dave Jones <davej@...hat.com>,
	Chuck Wolber <chuckw@...ntumlinux.com>,
	alan@...rguk.ukuu.org.uk, kiran@...lex86.org
Subject: Re: [stable] [patch 31/32] x86_64: fix boot hang due to nmi watchdog init code

* Chris Wright (chrisw@...s-sol.org) wrote:
> -stable review patch.  If anyone has any objections, please let us know.
> ------------------

replaced with upstream version, which is slightly changed by Andi.
--

From: Ravikiran G Thirumalai <kiran@...lex86.org>

2.6.19  stopped booting (or booted based on build/config) on our x86_64
systems due to a bug introduced in 2.6.19.  check_nmi_watchdog schedules an
IPI on all cpus to  busy wait on a flag, but fails to set the busywait
flag if NMI functionality is disabled.  This causes the secondary cpus
to spin in an endless loop, causing the kernel bootup to hang.
Depending upon the build, the  busywait flag got overwritten (stack variable)
and caused  the kernel to bootup on certain builds.  Following patch fixes
the bug by setting the busywait flag before returning from check_nmi_watchdog.
I guess using a stack variable is not good here as the calling function could
potentially return while the busy wait loop is still spinning on the flag.

AK: I redid the patch significantly to be cleaner

Signed-off-by: Ravikiran Thirumalai <kiran@...lex86.org>
Signed-off-by: Shai Fultheim <shai@...lex86.org>
Signed-off-by: Andi Kleen <ak@...e.de>
Signed-off-by: Chris Wright <chrisw@...s-sol.org>
---
 arch/i386/kernel/nmi.c   |    8 ++++----
 arch/x86_64/kernel/nmi.c |    9 +++++----
 2 files changed, 9 insertions(+), 8 deletions(-)

--- linux-2.6.19.orig/arch/i386/kernel/nmi.c
+++ linux-2.6.19/arch/i386/kernel/nmi.c
@@ -192,6 +192,8 @@ static __cpuinit inline int nmi_known_cp
 	return 0;
 }
 
+static int endflag __initdata = 0;
+
 #ifdef CONFIG_SMP
 /* The performance counters used by NMI_LOCAL_APIC don't trigger when
  * the CPU is idle. To make sure the NMI watchdog really ticks on all
@@ -199,7 +201,6 @@ static __cpuinit inline int nmi_known_cp
  */
 static __init void nmi_cpu_busy(void *data)
 {
-	volatile int *endflag = data;
 	local_irq_enable_in_hardirq();
 	/* Intentionally don't use cpu_relax here. This is
 	   to make sure that the performance counter really ticks,
@@ -207,14 +208,13 @@ static __init void nmi_cpu_busy(void *da
 	   pause instruction. On a real HT machine this is fine because
 	   all other CPUs are busy with "useless" delay loops and don't
 	   care if they get somewhat less cycles. */
-	while (*endflag == 0)
-		barrier();
+	while (endflag == 0)
+		mb();
 }
 #endif
 
 static int __init check_nmi_watchdog(void)
 {
-	volatile int endflag = 0;
 	unsigned int *prev_nmi_count;
 	int cpu;
 
--- linux-2.6.19.orig/arch/x86_64/kernel/nmi.c
+++ linux-2.6.19/arch/x86_64/kernel/nmi.c
@@ -190,6 +190,8 @@ void nmi_watchdog_default(void)
 		nmi_watchdog = NMI_IO_APIC;
 }
 
+static int endflag __initdata = 0;
+
 #ifdef CONFIG_SMP
 /* The performance counters used by NMI_LOCAL_APIC don't trigger when
  * the CPU is idle. To make sure the NMI watchdog really ticks on all
@@ -197,7 +199,6 @@ void nmi_watchdog_default(void)
  */
 static __init void nmi_cpu_busy(void *data)
 {
-	volatile int *endflag = data;
 	local_irq_enable_in_hardirq();
 	/* Intentionally don't use cpu_relax here. This is
 	   to make sure that the performance counter really ticks,
@@ -205,14 +206,13 @@ static __init void nmi_cpu_busy(void *da
 	   pause instruction. On a real HT machine this is fine because
 	   all other CPUs are busy with "useless" delay loops and don't
 	   care if they get somewhat less cycles. */
-	while (*endflag == 0)
-		barrier();
+	while (endflag == 0)
+		mb();
 }
 #endif
 
 int __init check_nmi_watchdog (void)
 {
-	volatile int endflag = 0;
 	int *counts;
 	int cpu;
 
@@ -253,6 +253,7 @@ int __init check_nmi_watchdog (void)
 	if (!atomic_read(&nmi_active)) {
 		kfree(counts);
 		atomic_set(&nmi_active, -1);
+		endflag = 1;
 		return -1;
 	}
 	endflag = 1;
-
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/