linux-kernel - [PATCH], issue EOI to APIC prior to calling crash_kexec in die

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: <20080206192555.GA24910@hmsendeavour.rdu.redhat.com>
Date:	Wed, 6 Feb 2008 14:25:55 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
	hpa@...or.com
Cc:	nhorman@...driver.com, kexec@...ts.infradead.org
Subject: [PATCH], issue EOI to APIC prior to calling crash_kexec in die_nmi path

Hey all-
	A hang on kdump was reported to me awhile back, only when systems died
via nmi watchdog panic.  The hang wouldn't always be in the same place, but it
would usually be somewhere down in purgatory.  In looking at the code, it
occured to me that since, during an nmi interrupt, we won't be able to handle
additional interrupts, that we won't be able to halt the other processors on a
system like we try to do in machine_crash_shutdown.  As such, it appears that
leaving the other cpus running exposes us to the risk that another processor
will encounter an error and halt the system while we are trying to boot the
kdump kernel, and that can result in a hang.  I wrote the attached patch to end
the nmi interrupt prior to calling crash_kexec from within die_nmi, and testing
here has proven successfull.

Regards
Neil

Signed-off-by: Neil Horman <nhorman@...driver.com>


 traps_32.c |    2 ++
 traps_64.c |    5 ++++-
 2 files changed, 6 insertions(+), 1 deletion(-)


diff --git a/arch/x86/kernel/traps_32.c b/arch/x86/kernel/traps_32.c
index 3cf7297..4443e8e 100644
--- a/arch/x86/kernel/traps_32.c
+++ b/arch/x86/kernel/traps_32.c
@@ -751,6 +751,8 @@ void __kprobes die_nmi(struct pt_regs *regs, const char *msg)
 	 * and might aswell get out now while we still can.
 	*/
 	if (!user_mode_vm(regs)) {
+		nmi_exit();
+		local_irq_enable();
 		current->thread.trap_no = 2;
 		crash_kexec(regs);
 	}
diff --git a/arch/x86/kernel/traps_64.c b/arch/x86/kernel/traps_64.c
index efc66df..0a50e70 100644
--- a/arch/x86/kernel/traps_64.c
+++ b/arch/x86/kernel/traps_64.c
@@ -608,8 +608,11 @@ void __kprobes die_nmi(char *str, struct pt_regs *regs, int do_panic)
 	 */
 	printk(str, smp_processor_id());
 	show_registers(regs);
-	if (kexec_should_crash(current))
+	if (kexec_should_crash(current)) {
+		nmi_exit();
+		local_irq_enable();
 		crash_kexec(regs);
+	}
 	if (do_panic || panic_on_oops)
 		panic("Non maskable interrupt");
 	oops_end(flags, NULL, SIGBUS);
-- 
/***************************************************
 *Neil Horman
 *nhorman@...driver.com
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/
--
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/