Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.

[Eric W. Biederman]

Hirokazu Takahashi <taka@xxxxxxxxxxxxx> writes:

> Hi Vivek and Eric,
> 
> IMHO, why don't we swap not only the contents of the top 640K
> but also kernel working memory for kdump kernel?
> 
> I guess this approach has some good points.
> 
>  1.Preallocating reserved area is not mandatory at boot time.
>    And the reserved area can be distributed in small pieces
>    like original kexec does.
> 
>  2.Special linking is not required for kdump kernel.
>    Each kdump kernel can be linked in the same way,
>    where the original kernel exists.
> 
> Am I missing something?

Preallocating the reserved area is largely to keep it from
being the target of DMA accesses.  Since we are not able
to shutdown any of the drivers in the primary kernel running
in a normal swath of memory sounds like a good way to get
yourself stomped at the worst possible time.

In addition we get to avoid running a lot of code in the
panic path if we are jumping to a contiguous region of memory 
with everything already setup.

To some extent this is a contest who has the better imagination
for things that can go wrong.  Real life on dying hardware and
kernels, or the programmers writing the diagnostic code.

But if it is a gamble you are willing to take it is quite
feasible to use the reserved region for what you are
proposing and you could run a standard kernel.

The other reason for running out of the reserved region is that
it actually requires less memory reserved.  Every byte you backup
needs to have a reserved area of memory to hold it.  And if you are
also going to fill that with meaningful content you need another
byte to hold the data.  So using a stock kernel probably requires
2/3 more memory.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/