[PATCH] Add call to non-crashing cores through IPI

Per Fransson per.fransson.ml at gmail.com
Mon Nov 22 12:03:03 EST 2010


On the other hand, do we really need to enable the interrupts before
performing an ipi?
The important thing must be for them to be enabled on the
receiving/callee cores. It's not
as if we want the crashing core to be interruptable, is it?

I tried it and it seems to work fine.

/Per

On Mon, Nov 22, 2010 at 3:40 PM, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Mon, Nov 22, 2010 at 03:31:24PM +0100, Per Fransson wrote:
>> On Mon, Nov 22, 2010 at 12:27 PM, Russell King - ARM Linux
>> <linux at arm.linux.org.uk> wrote:
>> > On Mon, Nov 22, 2010 at 10:47:40AM +0000, Russell King - ARM Linux wrote:
>> >> However, we do need smp_send_stop() to wait for a limited time for the
>> >> other CPUs to respond to the request.
>> >
>> > ARM: smp: make smp_send_stop() wait for secondary CPUs to stop
>> >
>> > Wait up to one second for secondary CPUs to respond to a request to
>> > stop.  This avoids the sender CPU continuing and possibly destroying
>> > state before the recipients have had a chance to respond to the stop.
>> > However, if the recipients have crashed, we won't hang the sender
>> > CPU indefinitely.
>> >
>>
>> The point of the crash kernel functionality is to make it possible to grab a
>> snapshot of the system at the time of the crash. smp_send_stop() will
>> take the other cores offline, which makes the snapshot differ from the
>> crash state more than it has to. To be more concrete, any core dump
>> analysis tool which reads the cpu_online_mask to determine the number
>> of cpus in use will get an incorrect picture.
>
> Well, you can't go around randomly enabling interrupts to call functions
> that require interrupts to be enabled, so I guess it's not possible to
> save the state of the other cores.
>
> I guess you're going to have to come up with another solution.
>



More information about the kexec mailing list