linux-kernel - Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu

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

Date:	Fri, 7 Dec 2007 13:48:10 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Neil Horman <nhorman@...hat.com>, Ben Woodard <woodard@...hat.com>,
	kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Andi Kleen <ak@...e.de>, hbabu@...ibm.com,
	Andi Kleen <andi@...stfloor.org>,
	Yinghai Lu <yhlu.kernel@...il.com>,
	Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on
	boot cpu

On Fri, Dec 07, 2007 at 11:36:58AM -0700, Eric W. Biederman wrote:
> Neil Horman <nhorman@...hat.com> writes:
> 
> > this seems reasonable, I can reroll the patch for this.  As I think about it I'm
> > also going to update the patch to make this check occur for any pci class 0600
> > device from vendor AMD, since its possible that more than just nvidia chipsets
> > can be affected.
> >
> > I'll repost as soon as I've tested, thanks!
> 
> Thanks.
> 
> Neil in your testing please confirm the preconditions for setting 
> the Apic Extended Broadcast flag (bit 17) are present.
> 
The systems that I have here do _not_ in fact have that precondition, but the
systems from Ben, who originoally reported the problem do have that
precondition, and he has reported that this fixes the hang in the kdump boot.

> If that is the case it makes sense to always set that bit on conforming
> systems but we will also want to print a message noting that the
> BIOS has a bug, and we are working around it.
> 
I've got two printk's in this patch, one that indicates that Extended APIC ID's
are in use, and a second that indicates that there is a mismatch between the use
of extended APIC ids (bit 18) and the lack of an extended APIC id dest mask for
interrupt packets (bit 17).  Not sure if that meets you're requirements, but I
think its sufficient.  If you disagree, let me know and we can enhance them.

Thanks
Neil

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