All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Will Deacon <will.deacon@arm.com>
Cc: "linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"vijay.kilari@gmail.com" <vijay.kilari@gmail.com>,
	"Prasun.Kapoor@caviumnetworks.com"
	<Prasun.Kapoor@caviumnetworks.com>,
	Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ARM: kexec: offline non panic CPUs on Kdump panic
Date: Fri, 26 Jul 2013 11:08:07 -0600	[thread overview]
Message-ID: <51F2ACF7.9000008@wwwdotorg.org> (raw)
In-Reply-To: <20130726104908.GC17886@mudshark.cambridge.arm.com>

On 07/26/2013 04:49 AM, Will Deacon wrote:
> [Adding Stephen Warren since he has been working in this area]
> 
> On Fri, Jul 26, 2013 at 06:41:27AM +0100, vijay.kilari@gmail.com wrote:
>> From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>>
>> In case of normal kexec kernel load, all cpu's are offlined
>> before calling machine_kexec() under kernel_kexec() function.
>> But in case crash panic cpus are relaxed in
>> machine_crash_nonpanic_core() SMP function but not offlined.
>>
>> When crash kernel is loaded with kexec and on panic trigger
>> machine_kexec() checks for number of cpus online.
>> If more than one cpu is online machine_kexec() fails to load
>> with below error
>>
>> kexec: error: multiple CPUs still online
>>
>> In machine_crash_nonpanic_core() SMP function, offline CPU
>> before cpu_relax

>> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c

>> @@ -73,6 +73,7 @@ void machine_crash_nonpanic_core(void *unused)
>>  	crash_save_cpu(&regs, smp_processor_id());
>>  	flush_cache_all();
>>  
>> +	set_cpu_online(smp_processor_id(), false);
>>  	atomic_dec(&waiting_for_crash_ipi);
>>  	while (1)
>>  		cpu_relax();
> 
> Ok, I guess this will work since the new kernel is loaded somewhere higher
> in memory and the crashed kernel will stick around, so the non-crashing CPUs
> can sit around spinning.

Does a kernel that's used as the crash kernel guarantee:

* Never to re-use the memory that was used by the previous kernel, so
that the spin loop code/data won't be corrupted, ever, no matter how
long the crash recovery kernel runs.

* Not use SMP, so there's never a need to re-activate the non-boot CPUs,
which might not work if they aren't truly disabled but rather just
running a pin loop?

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: kexec: offline non panic CPUs on Kdump panic
Date: Fri, 26 Jul 2013 11:08:07 -0600	[thread overview]
Message-ID: <51F2ACF7.9000008@wwwdotorg.org> (raw)
In-Reply-To: <20130726104908.GC17886@mudshark.cambridge.arm.com>

On 07/26/2013 04:49 AM, Will Deacon wrote:
> [Adding Stephen Warren since he has been working in this area]
> 
> On Fri, Jul 26, 2013 at 06:41:27AM +0100, vijay.kilari at gmail.com wrote:
>> From: Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>
>>
>> In case of normal kexec kernel load, all cpu's are offlined
>> before calling machine_kexec() under kernel_kexec() function.
>> But in case crash panic cpus are relaxed in
>> machine_crash_nonpanic_core() SMP function but not offlined.
>>
>> When crash kernel is loaded with kexec and on panic trigger
>> machine_kexec() checks for number of cpus online.
>> If more than one cpu is online machine_kexec() fails to load
>> with below error
>>
>> kexec: error: multiple CPUs still online
>>
>> In machine_crash_nonpanic_core() SMP function, offline CPU
>> before cpu_relax

>> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c

>> @@ -73,6 +73,7 @@ void machine_crash_nonpanic_core(void *unused)
>>  	crash_save_cpu(&regs, smp_processor_id());
>>  	flush_cache_all();
>>  
>> +	set_cpu_online(smp_processor_id(), false);
>>  	atomic_dec(&waiting_for_crash_ipi);
>>  	while (1)
>>  		cpu_relax();
> 
> Ok, I guess this will work since the new kernel is loaded somewhere higher
> in memory and the crashed kernel will stick around, so the non-crashing CPUs
> can sit around spinning.

Does a kernel that's used as the crash kernel guarantee:

* Never to re-use the memory that was used by the previous kernel, so
that the spin loop code/data won't be corrupted, ever, no matter how
long the crash recovery kernel runs.

* Not use SMP, so there's never a need to re-activate the non-boot CPUs,
which might not work if they aren't truly disabled but rather just
running a pin loop?

  reply	other threads:[~2013-07-26 17:08 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-26  5:41 [PATCH] ARM: kexec: offline non panic CPUs on Kdump panic vijay.kilari
2013-07-26  5:41 ` vijay.kilari at gmail.com
2013-07-26 10:49 ` Will Deacon
2013-07-26 10:49   ` Will Deacon
2013-07-26 17:08   ` Stephen Warren [this message]
2013-07-26 17:08     ` Stephen Warren
2013-07-26 17:11     ` Will Deacon
2013-07-26 17:11       ` Will Deacon
2013-07-30 10:37     ` Vijay Kilari
2013-07-30 10:37       ` Vijay Kilari
2013-07-30 16:59       ` Stephen Warren
2013-07-30 16:59         ` Stephen Warren
2013-07-31 11:37         ` Vijay Kilari
2013-07-31 11:37           ` Vijay Kilari
2013-07-31 17:14           ` Stephen Warren
2013-07-31 17:14             ` Stephen Warren
2013-08-01 13:49             ` Vijay Kilari
2013-08-01 13:49               ` Vijay Kilari
2013-08-01 16:25               ` Stephen Warren
2013-08-01 16:25                 ` Stephen Warren
2013-08-12 12:18                 ` Vijay Kilari
2013-08-12 12:18                   ` Vijay Kilari
2013-08-13 11:18                   ` Will Deacon
2013-08-13 11:18                     ` Will Deacon
2013-07-26 17:05 ` Stephen Warren
2013-07-26 17:05   ` Stephen Warren
2013-07-30 10:05   ` Vijay Kilari
2013-07-30 10:05     ` Vijay Kilari
2013-07-30 16:57     ` Stephen Warren
2013-07-30 16:57       ` Stephen Warren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51F2ACF7.9000008@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=Prasun.Kapoor@caviumnetworks.com \
    --cc=Vijaya.Kumar@caviumnetworks.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@arm.linux.org.uk \
    --cc=vijay.kilari@gmail.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.