[PATCH 2/2] makedumpfile: Use max_pfn from mem_map array

[Michael Holzheu]

On Mon, 31 Mar 2014 09:48:05 +0000
Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp> wrote:

> [snip]
> 
> >> > That's because the bitmap length is calculated in prepare_bitmap_buffer
> >> > using info->max_mapnr, but create_1st_bitmap() still loops over all
> >> > PT_LOAD segments, calling set_bit_on_1st_bitmap() for each PFN. The
> >> > offset may easily fall beyond the bitmap size.
> >>
> >> What about the following patch. It works for me when I specify
> >> the "--non-cyclic" option.
> >>
> >> Michael
> >> ---
> >> [PATCH] makedumpfile: Fix bitmap create for adjusted info->max_mapnr
> >>
> >> If info->max_mapnr has been adjusted, for example because the dumped
> >> system has specified the "mem=" kernel parameter, makedumpfile writes
> >> the following error messages for Xen dumps or when the "--non-cyclic"
> >> option has been specified:
> >>
> >> set_bitmap: Can't read the bitmap(/tmp/kdump_bitmap96s9V8). Success
>                                                                ^^^^^^^^
> This looks confusing, is it an actual message ?
> I suppose it must be "Invalid argument" like Petr's log.

Right, I get "Invalid argument".

No idea from where I pasted "Success" here...

> >>
> >> Fix this and consider "info->max_mapnr" in the create bitmap functions.
> >>
> >> Signed-off-by: Michael Holzheu <holzheu at linux.vnet.ibm.com>
> >> ---
> >

[snip]

> I found another issue of truncating max_mapnr for Xen.
> 
> The bitmap manages MFN(machine frame number) for Xen
> while __exclude_unnecessary_pages() treats PFN(guest-physical frame number).
> __exclude_unnecessary_pages() expects that all bits of PFNs
> are mapped in the bitmap even if it was reduced by truncated 
> max_mapnr. However, PtoM mapping isn't linear(probably...),
> there is no guarantee that a set of continuous PFNs is mapped
> in a set of continuous MFNs.
> So the actual I/O offset can exceed the bitmap size when the
> bitmap size is reduced.
> 
> In the first place, we shouldn't truncate max_mapnr
> based on dom0's mem_section since there are some domU's
> memories on Xen dumps. Now, I think a better way for Xen
> is just leaving max_mapnr as it is.
> 
> Do you agree with my view ?

I don't know the Xen details so I would leave it to Petr
to answer this question.

Michael