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 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: <m1y7cjkec2.fsf@ebiederm.dsl.xmission.com>
Date:	Tue, 27 Nov 2007 06:28:13 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Neil Horman <nhorman@...hat.com>
Cc:	Neil Horman <nhorman@...driver.com>, hbabu@...ibm.com,
	vgoyal@...ibm.com, kexec@...ts.infradead.org, ak@...e.de,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu

Neil Horman <nhorman@...hat.com> writes:

> What makes you say this?  I don't see any need for interrupts prior to
> calibrate_delay()

Yes.  calibrate_delay() is the first place we send interrupts over
hypertransport.  However I/O still works.  Thus hypertransport from
the first cpu is working, and hypertransport itself is working.

This is an interrupt specific problem not some generic hypertransport
problem.

>> I agree that there is a problem.
>> 
>> The reliable fix is to totally skip the PIC interrupt mode and go directly
>> to apic mode.
>> 
>> To make the code kexec on panic code path reliable we need to remove code
>> not add it.
>> 
>> Frankly I think switching cpus is one of the least reliable things that
>> we can do in general.
>> 
> I understand the sentiment here, but its not like we're adding additional
> functionality with this patch.  We're already sending an IPI to all the
> processors to halt them

And we don't care if they halt.  If they don't get the IPI we timeout.
Making the IPI mandatory is a _singificant_ change.

The only reason that code is on the kexec on panic code path is that
there is no other possible place we could put it.

> , we're just adding logic here so that we can detect the
> boot cpu and use it to jump to the kexec image instead of halting.  I don't
> think this is any less reliable that what we have currently.

It doesn't make things more reliable, and it adds code to a code path
that already has to much code to be solid reliable (thus your
problem). 

Putting the system back in PIC legacy mode on the kexec on panic path
was supposed to be a short term hack until we could remove the need
by always deliver interrupts in apic mode.

If you can't root cause your problem and figure out how the apics
are misconfigured for legacy mode let's remove the need for going into
to legacy PIC mode and do what we should be able to do reliably.  The
reward is much higher, as we kill all possibility of restoring PIC
mode wrong because we don't need to bother.

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/