Re: kdump failed because of hotplug memory adding in kdump kernel

[Toshi Kani <toshi.kani@hp.com>]

On Fri, 2014-01-10 at 15:11 +0800, Baoquan wrote:
> On 01/09/14 at 02:56pm, Toshi Kani wrote:
 :
> > I am more curious to know how makedumpfile decides what memory ranges to
> > dump.  The 1st kernel may have performed memory hot-add / delete
> > operations before a crash, so it needs to know the valid physical
> > address range at the time of crash, and may not rely on the E820 map
> > from BIOS (which is stale).  Am I right to assume that makedumpfile gets
> > it from the page tables of the 1st kernel?
> 
> makedumpfile just do the dump, what memory ranges to dump is decided in
> 1st kernel by kexec-tools. In 1st kernel, if kexec-tools executed, it
> will find all System Ram memorys which exclude the reserved regions for
> kdump kernel, then build a logical elf file, each load segment is one of
> these System Ram memory regions, its addr and length is written into the
> program header.
> 
> Then makedumpfile just read this elf file, and read all of them and
> dump.
> 
> If after kexec-tools execution and before crash, a hotplug memory is
> removed, udev will check this and trigger a kdump restart, kexec-tools
> is executed again, System Ram region information are stored. The logical
> file header will be passed to 2nd kernel.

Oh, that's how it works.  Thanks for the explanation!  In case of
hot-delete, ideally, the elf file should be updated after a memory
region is put into off-line, but before it is ejected.  But it is
difficult/vulnerable to coordinate such sequence with user space.  So,
the current scheme sounds good to me.

Thanks,
-Toshi