From: Stephen Warren <swarren@wwwdotorg.org>
To: Vijay Kilari <vijay.kilari@gmail.com>
Cc: "linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
"Prasun.Kapoor@caviumnetworks.com"
<Prasun.Kapoor@caviumnetworks.com>,
Will Deacon <will.deacon@arm.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: Thu, 01 Aug 2013 10:25:55 -0600 [thread overview]
Message-ID: <51FA8C13.2060807@wwwdotorg.org> (raw)
In-Reply-To: <CALicx6u5tkf_wvX8ZcVwbhUOkt3=Zz7214yR9pVce0TJ82Vt4A@mail.gmail.com>
On 08/01/2013 07:49 AM, Vijay Kilari wrote:
> On Wed, Jul 31, 2013 at 10:44 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 07/31/2013 05:37 AM, Vijay Kilari wrote:
>>> On Tue, Jul 30, 2013 at 10:29 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>> On 07/30/2013 04:37 AM, Vijay Kilari wrote:
>>>>> On Fri, Jul 26, 2013 at 10:38 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>> ...
>>>>>> 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?
>>>>>
>>>>> From cat /proc/iomem, normal kernel is executed from (0x80xxxxxx) with crash
>>>>> kernel reserved 64M@0xa0000000
>>>>>
>>>>> 80000000-bfffffff : System RAM
>>>>> 80008000-805aeddf : Kernel code
>>>>> 805e2000-8063e427 : Kernel data
>>>>> a0000000-a3ffffff : Crash kernel
>>>>>
>>>>> crash kernel is loaded to reserved memory location and is executed from there.
>>>>> I could confirm this from /proc/iomem when crash kernel is running
>>>>>
>>>>> a0000000-a3efffff : System RAM
>>>>> a0008000-a05aeddf : Kernel code
>>>>> a05e2000-a063e427 : Kernel data
>>>>
>>>> OK, but in the crash dump kernel, is 80008000..8063e427 reserved as
>>>> well, which would guarantee that the spin loop being executed by the
>>>> non-crash CPUs won't be corrupted?
>>>
>>> The crash dump kernel runs from reserved memory area (0xa0000000 - 0xa3effffff).
>>> So it should not corrupt the memory area of original kernel that was running
>>> at 0x80000000,where other CPU's are in spin loop.
>>
>> What about dynamic allocations?
>
> IMHO, it is the kdump functionality to ensure that it won't corrupt
> original kernel's dynamic allocations
OK, if there are explicit measure to assure this already, then there's
no issue.
_______________________________________________
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: Thu, 01 Aug 2013 10:25:55 -0600 [thread overview]
Message-ID: <51FA8C13.2060807@wwwdotorg.org> (raw)
In-Reply-To: <CALicx6u5tkf_wvX8ZcVwbhUOkt3=Zz7214yR9pVce0TJ82Vt4A@mail.gmail.com>
On 08/01/2013 07:49 AM, Vijay Kilari wrote:
> On Wed, Jul 31, 2013 at 10:44 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 07/31/2013 05:37 AM, Vijay Kilari wrote:
>>> On Tue, Jul 30, 2013 at 10:29 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>> On 07/30/2013 04:37 AM, Vijay Kilari wrote:
>>>>> On Fri, Jul 26, 2013 at 10:38 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>>> ...
>>>>>> 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?
>>>>>
>>>>> From cat /proc/iomem, normal kernel is executed from (0x80xxxxxx) with crash
>>>>> kernel reserved 64M at 0xa0000000
>>>>>
>>>>> 80000000-bfffffff : System RAM
>>>>> 80008000-805aeddf : Kernel code
>>>>> 805e2000-8063e427 : Kernel data
>>>>> a0000000-a3ffffff : Crash kernel
>>>>>
>>>>> crash kernel is loaded to reserved memory location and is executed from there.
>>>>> I could confirm this from /proc/iomem when crash kernel is running
>>>>>
>>>>> a0000000-a3efffff : System RAM
>>>>> a0008000-a05aeddf : Kernel code
>>>>> a05e2000-a063e427 : Kernel data
>>>>
>>>> OK, but in the crash dump kernel, is 80008000..8063e427 reserved as
>>>> well, which would guarantee that the spin loop being executed by the
>>>> non-crash CPUs won't be corrupted?
>>>
>>> The crash dump kernel runs from reserved memory area (0xa0000000 - 0xa3effffff).
>>> So it should not corrupt the memory area of original kernel that was running
>>> at 0x80000000,where other CPU's are in spin loop.
>>
>> What about dynamic allocations?
>
> IMHO, it is the kdump functionality to ensure that it won't corrupt
> original kernel's dynamic allocations
OK, if there are explicit measure to assure this already, then there's
no issue.
next prev parent reply other threads:[~2013-08-01 16:25 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
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 [this message]
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=51FA8C13.2060807@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.