On Thu, Aug 1, 2013 at 9:55 PM, Stephen Warren [off-list ref] wrote:

On 08/01/2013 07:49 AM, Vijay Kilari wrote:

quoted

On Wed, Jul 31, 2013 at 10:44 PM, Stephen Warren [off-list ref] wrote:

quoted

On 07/31/2013 05:37 AM, Vijay Kilari wrote:

quoted

On Tue, Jul 30, 2013 at 10:29 PM, Stephen Warren [off-list ref] wrote:

quoted

On 07/30/2013 04:37 AM, Vijay Kilari wrote:

quoted

On Fri, Jul 26, 2013 at 10:38 PM, Stephen Warren [off-list ref] wrote:

...

quoted

quoted

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.

Hi Will,

 Can you please consider this patch?

Thanks & Regards
Vijay