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]

Date:	Mon, 13 Feb 2012 04:52:10 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	linux-kernel@...r.kernel.org, mingo@...hat.com, hpa@...or.com,
	torvalds@...ux-foundation.org, kexec@...ts.infradead.org,
	vgoyal@...hat.com, akpm@...ux-foundation.org, tglx@...utronix.de,
	dzickus@...hat.com, mingo@...e.hu,
	linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in crash path

Yinghai Lu <yinghai@...nel.org> writes:

> On Sat, Feb 11, 2012 at 7:13 PM, Eric W. Biederman
> <ebiederm@...ssion.com> wrote:
>> Yinghai Lu <yinghai@...nel.org> writes:
>>> After reverting this commit, kdump is working again.
>>>
>>> So assume you need to drop this patch.
>>
>> It sounds like there is a bug in ioapic initialization in the context of
>> VT-d.  Where do you fail?
>>
> before get debug print out from second kernel, the system get reset.

Ouch.

Don can you work with with Yinghai to figure out what is different
between your test configuration and his?

YH did you have early printk enabled?

YH Did I understand you properly that things work if you don't enable
VT-d?   By VT-d are you referring to interrupt remapping?

For anyone watching.  The premise of this patch was that we can boot
the kernel without resorting to legacy tricks that require us to
put the interrupt controllers in PIT mode.

Apparently there is some weird corner case that YH can reproduce that
Don did not have in his test set that YH does that causes things to
fail.

I really don't see any likely candidates when looking at the code.  The
most I can see is some code that we don't run when interrupt remapping
is enabled in disable_IO_APIC.

So I suspect we have a bug in our apic initialization somewhere, but
apic initialization should happen after printk are enabled.  Or at least
after early printks so the reset YH is reporting doesn't make much sense.

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