makedumpfile: get_max_mapnr() from ELF header problem

[Atsushi Kumagai]

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 ?

At least, if the tools respect the actual memory map like /proc/vmcore, it
can create correct ELF headers and makedumpfile will work normally.

>Unfortunately in "get_max_mapnr()" makedumpfile uses the ELF header to
>get the maxmimum page frame number. Since this is not the correct value
>in our case makedumpfile fails to filter the dump.

makedumpfile depends on the ELF file format, you know.
I think you should fix the tools to create correct ELF files.


Thanks
Atsushi Kumagai

>We get the following error on s390 with makedumpfile version 1.5.3:
>
>makedumpfile -c -d 31 vmcore dump.kdump
>cyclic buffer size has been changed: 22156083 => 22156032
>Excluding unnecessary pages        : [ 21 %] vtop_s390x: Address too big for the number of page table levels.
>readmem: Can't convert a virtual address(8000180104670) to physical address.
>readmem: type_addr: 0, addr:8000180104670, size:32768
>__exclude_unnecessary_pages: Can't read the buffer of struct page.
>Excluding unnecessary pages        : [ 23 %] vtop_s390x: Address too big for the number of page table levels. readmem:
>Can't convert a
>virtual address(8000180104670) to physical address. readmem: type_addr:
>0, addr:8000180104670, size:327681.5.5 __exclude_unnecessary_pages:
>Can't read the buffer of struct page.
>
>Since version 1.5.4 makedumpfile seems to loop in __exclude_unnecessary_pages().
>
>We thought about several ways to fix this problem but have not found a
>good solution up to now.
>
>Do you have an idea how we could fix that?
>
>Best Regards,
>Michael