>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
