linux-kernel - Re: [PATCH] x86, kdump: No need to disable ioapic 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m1r4y6i5cw.fsf@fess.ebiederm.org>
Date:	Tue, 07 Feb 2012 15:35:59 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Don Zickus <dzickus@...hat.com>, x86@...nel.org,
	LKML <linux-kernel@...r.kernel.org>,
	kexec-list <kexec@...ts.infradead.org>
Subject: Re: [PATCH] x86, kdump: No need to disable ioapic in crash path

Vivek Goyal <vgoyal@...hat.com> writes:

> On Tue, Feb 07, 2012 at 04:57:41PM -0500, Don Zickus wrote:
>> On Thu, Feb 02, 2012 at 03:24:46PM -0800, Eric W. Biederman wrote:
>> > > Eric, brought up a point that because the boot code was restructured we may
>> > > not need to disable the io apic any more in the crash path.  The original
>> > > concern that led to the development of disable_IO_APIC, was that the TSC
>> > > calibration on boot up relied on the PIT timer for reference.  Access
>> > > to the PIT required 8259 interrupts to be working.  This wouldn't work
>> > > if the ioapic needed to be configured.  So on panic path, the ioapic was
>> > > reconfigured to use virtual wire mode to allow the 8259 to passthrough.
>> > 
>> > A small clarification originally it was the jiffies calibration that
>> > would fail if we could cause the PIT to generate interrupts through the
>> > 8259.  The boot would then hang at calibrating jiffies.
>> 
>> Ok.  Thanks!
>
> So now what has changed? Do we setup LAPIC and IOAPIC early enough to
> receive PIT interrupts in regular mode (non-virtual wire mode) or
> something else?

Yes.  Part of the Moorstown work required that this be done because
moorsetown did not support legacy mode.  Last I looked the code hadn't
been generalized beyond Moorsetown but empirically it works now.

Don as to what to test the only case I can think of that might be spooky
is a screaming interrupt during the handover.  You might want to try
playing with lkcdtm to try some of the more exotic crash scenarios.  But
all I expect further testing might reveal are places where we are not
as robust in initializing the hardware as we might be.  Things that
might have been papered over by the ioapic shutdown.

I think we are good to remove my ancient hack of disabling the ioapics,
and putting the system into PIT during the crash kernel switchover.

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/