linux-kernel - Re: [PATCH] x86, kdump, ioapic: Fix kdump race with migrating irq

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: <m1vcnr33c8.fsf@fess.ebiederm.org>
Date:	Tue, 31 Jan 2012 14:38:15 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Don Zickus <dzickus@...hat.com>
Cc:	x86@...nel.org, LKML <linux-kernel@...r.kernel.org>,
	vgoyal@...hat.com, kexec-list <kexec@...ts.infradead.org>
Subject: Re: [PATCH] x86, kdump, ioapic: Fix kdump race with migrating irq

Don Zickus <dzickus@...hat.com> writes:

> On Tue, Jan 31, 2012 at 02:08:29PM -0800, Eric W. Biederman wrote:
>> > The problem is that although kdump tries to shutdown minimal hardware,
>> > it still needs to disable the IO APIC.  This requires spinlocks which
>> > may be held by another cpu.  This other cpu is being held infinitely in
>> > an NMI context by kdump in order to serialize the crashing path.  Instant
>> > deadlock.
>> 
>> Can you test to see if kexec on panic still needs to disable the IO
>> APIC.  Last I looked we were close if not all of the way there to not
>> needing to boot the kernel in pic mode?
>
> Ok, so you just blindly remove disable_IO_APIC from
> native_machine_crash_shutdown and re-run some panic tests on various
> machines?  What about the disable_IO_APIC path in native_machine_shutdown?
>

Yes.  Just native_machine_crash_shutdown.

native_machine_shutdown is the case when all is good and we attempt to
put the hardware back the way we found it.

Any normal x86 machine that the kernel runs in ioapic mode should be
enough to get a first approximation.

> Also, where could I look to see if that work was done?  Is that in the
> ioapic setup code?

The primary question is do we call the ioapic setup code without calling
the pic setup code first.  On some embedded x86 platforms we certainly
do.  I don't know if that code has been generalized.

Historically the problem is that we started the pit timer in pic mode
and used that to calibrate the delay loop.

So what we are looking to verify is that the linux kernel boot skip
pic mode entirely.

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/