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
