[PATCH 3/3] makedumpfile: Rewrite readpage_elf

[Atsushi Kumagai]

>On Wed, Feb 10, 2016 at 08:50:09AM +0100, Petr Tesarik wrote:
>> The current code in readpage_elf (and readpage_elf_parallel) is extremely
>> hard to follow. Additionally, it still does not cover all possible cases.
>> For example, attempts to read outside of any ELF segment will end up with
>> phys_start being 0, frac_head a negative number, interpreted as a large
>> positive number by memset() and write past buffer end.
>>
>> Instead of trying to handle even more "corner cases", I rewrote the
>> algorithm from scratch. The basic idea is simple: set a goal to fill the
>> page buffer with data, then work towards that goal by:
>>
>>   - filling holes with zeroes (see Note below),
>>   - p_filesz portions with file data and
>>   - remaining p_memsz portions again with zeroes.
>>
>> Repeat this method for each LOAD until the goal is achieved, or an error
>> occurs. In most cases, the loop runs only once.
>>
>> Note: A "hole" is data at a physical address that is not covered by any
>> ELF LOAD program header. In other words, the ELF file does not specify
>> any data for such a hole (not even zeroes). So, why does makedumpfile
>> fill them with zeroes? It's because makedumpfile works with page
>> granularity (the compressed format does not even have a way to store
>> a partial page), so if only part of a page is stored, a complete page
>> must be provided to make this partial data accessible.
>>
>> Credits to Ivan Delalande <colona at arista.com> who first found the
>> problem and wrote the original fix.
>>
>> Signed-off-by: Petr Tesarik <ptesarik at suse.com>
>
>Tested-by: Ivan Delalande <colona at arista.com>
>
>Dump-dmesg works well and gives the expected results with our various
>setups (x86_64 only). Thanks for your work Petr!

Thanks for your great work, Petr and Ivan.
I'll merge this patch set into v1.6.0.


Thanks,
Atsushi Kumagai