makedumpfile: get_max_mapnr() from ELF header problem

[Michael Holzheu]

On Tue, 25 Mar 2014 01:14:21 +0000
Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp> wrote:

[snip]

> >But it looks like get_mm_sparsemem() does not check for zero.
> >The nr_to_section() function just returns an invalid address
> >(something between 0 and 4096) for section in case we get zero
> >from the "mem_section" entry. This is address is then used for
> >calculating "mem_map":
> 
> In other architectures, the check by is_kaddr() avoids to
> read invalid address, but it doesn't do anything in the case
> of s390 due to the its memory management mechanism:
> 
> s390x: Fix KVBASE to correct value for	s390x architecture.
> http://lists.infradead.org/pipermail/kexec/2011-March/004930.html

Right, for s390 the zero page is valid.
 
> Finally I've understood the cause of this issue completely,
> thanks for your report.
> 
> >mem_map = section_mem_map_addr(section);
> >mem_map = sparse_decode_mem_map(mem_map, section_nr);
> >
> >With the patch below I could use makedumpfile (1.5.3) successfully
> >on the 1TB dump with mem=1G. I attached the -D output that is
> >created by makedumpfile with the patch.
> >
> >But compared to my first patch it takes much longer and the resulting
> >dump is bigger (version 1.5.3):
> >
> >             | Dump time   | Dump size
> >-------------+-------------+-----------
> >First patch  |  10 sec     |  124 MB
> >Second patch |  87 minutes | 6348 MB
> >
> >No idea why the dump is bigger with the second patch. I think the time
> >is consumed in write_kdump_pages_cyclic() by checking for zero pages
> >for the whole range:
> 
> I suppose this difference was resolved with the v2 of the second patch,
> right?

Right, with the last patch the dump time and size were ok.

[snip]

> >So the first patch would be better for my scenario. What in particular are your
> >concerns with that patch?
> 
> I think the v2 second patch is a reasonable patch to fix the
> bug of get_mm_sparsemem().
> Additionally, the latest patch you posted to adjust max_mapnr
> (which using mem_map_data[]) is acceptable instead of the first
> patch.
> So could you re-post the two as a formal patch set?
> I mean patch descriptions and your signature are needed.

Ok great! I will resend the patches.

Michael