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! -- Ivan "Colona" Delalande Arista Networks
