linux-kernel - Re: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in crash path

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: <20120307155018.GA13430@redhat.com>
Date:	Wed, 7 Mar 2012 10:50:18 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Fernando Luis Vázquez Cao 
	<fernando@....ntt.co.jp>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Don Zickus <dzickus@...hat.com>,
	linux-tip-commits@...r.kernel.org, Yinghai Lu <yinghai@...nel.org>,
	mingo@...e.hu, kexec@...ts.infradead.org,
	linux-kernel@...r.kernel.org, mingo@...hat.com, hpa@...or.com,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	tglx@...utronix.de
Subject: Re: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in
 crash path

On Wed, Mar 07, 2012 at 07:53:16PM +0900, Fernando Luis Vázquez Cao wrote:
> On 03/01/2012 08:19 AM, Eric W. Biederman wrote:
> 
> >Don Zickus<dzickus@...hat.com>  writes:
> >>It probably is, except I never hacked on idt code before and my assembly
> >>isn't that good.  I have been trying to find examples to copy from to give
> >>it a try.  So far I was using early_idt_handlers with early_printk to see
> >>if I could capture some printk messages while jumping from the first
> >>kernel to the second kernel (when the other early_idt_handlers would kick
> >>in for the second kernel).
> >>
> >>Tips?  Better examples?
> >That is a particularly good example.  When I took a quick look earlier
> >that is the first place we reload the idt in the kernel boot so that is
> >one of two places that needs to be modified.
> 
> Hi Eric, Don
> 
> Sorry for chiming in so late.
> 
> We run into the same NMI problems and wrote some patches that tackle
> the kernel boot side of things. They have been extensively tested using
> qemu-kvm and things seem to be working as expected (after receiving an
> early NMI the kernel continues without problem; after the iret there is no
> stack corruption or register corruption).

What happens if NMI happens while we are still in purgatory code?

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