makedumpfile: get_max_mapnr() from ELF header problem

[Atsushi Kumagai]

>On Mon, 3 Mar 2014 03:11:23 +0000
>Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp> wrote:
>
>> Hello Michael,
>>
>> >Hello Atsushi,
>> >
>> >On s390 we have the following little problem:
>> >
>> >We use hypervisor or stand-alone dump tools to create Linux system
>> >dumps. These tools do not know the kernel parameter line and dump the
>> >full physical memory.
>> >
>> >We use makedumpfile to filter those dumps.
>> >
>> >If a Linux system has specified the "mem=" parameter, the dump tools
>> >still dump the whole phypsical memory.
>>
>> I guess this is a problem of the tools, it sounds that the tools ignore
>> the actual memory map and just make wrong ELF headers.
>> How do the tools decide the range of System RAM to create ELF headers ?
>
>The tools do a physical memory detection and that defines the range
>of memory to be dumped and also defines the memory chunks for the
>ELF header.

makedumpfile is designed for kdump, this means it relies on dependable ELF
headers. If we support such an incorrect ELF header, makedumpfile has to get
the actual memory map from vmcore (but I have no ideas how to do it now) and
re-calculate all PT_LOAD regions with it. It sounds too much work for
irregular case, I don't plan to take care of it now.

>And I think we are not the only ones that have this problem. For example,
>the KVM virsh dump probably also has that problem.

virsh dump seems to have the same issue as you said, but I suppose qemu
developers don't worry about that because they are developing an original
way to dump guest's memory in kdump-compressed format as "dump-guest-memory"
command. It seems that they know such case is out of the scope of makedumpfile.


Thanks
Atsushi Kumagai

>> At least, if the tools respect the actual memory map like /proc/vmcore, it
>> can create correct ELF headers and makedumpfile will work normally.
>
>As I said, the tools do not know the Linux memory map. They only know
>the physical available memory.
>
>Michael
>
>
>_______________________________________________
>kexec mailing list
>kexec at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/kexec