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

On Wed, Feb 06, 2008 at 02:40:40PM -0500, Vivek Goyal wrote:
> On Wed, Feb 06, 2008 at 02:25:55PM -0500, Neil Horman wrote:
> > 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.
> > 
> 
> Hi Neil,
> 
> Why wouldn't I be able to stop other cpus if I am inside an NMI handler? I
> just need to send an NMI IPI to other cpus and they should be able to
> receive and handle it?
> 
> Thanks
> Vivek
> 
Can an APIC accept an NMI while already handling an NMI?  I didn't think they
would interrupt one another, but rather, pend until such time as the previous
NMI was cleared
Neil

> _______________________________________________
> kexec mailing list
> kexec@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

-- 
/***************************************************
 *Neil Horman
 *Software Engineer
 *Red Hat, Inc.
 *nhorman@...hat.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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ