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

[Atsushi Kumagai]

[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.

>>
>> Fix this and consider "info->max_mapnr" in the create bitmap functions.
>>
>> Signed-off-by: Michael Holzheu <holzheu at linux.vnet.ibm.com>
>> ---
>
>[snip]
>
>> @@ -7575,6 +7581,9 @@ exclude_xen4_user_domain(void)
>>  		pfn     = paddr_to_pfn(phys_start);
>>  		pfn_end = paddr_to_pfn(phys_end);
>>  		size    = pfn_end - pfn;
>> +		if (pfn > info->max_mapnr)
>> +			continue;
>> +		pfn_end = MIN(phys_end, info->max_mapnr);
>
>Hmm, probably time for weekend. Of course this should be:
>
>pfn_end = MIN(pfn_end, info->max_mapnr);
>
>Here the updated patch:

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 ?


Thanks
Atsushi Kumagai

>---
>[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
>
>Fix this and consider "info->max_mapnr" in the create bitmap functions.
>
>Signed-off-by: Michael Holzheu <holzheu at linux.vnet.ibm.com>
>---
> makedumpfile.c |    9 +++++++++
> 1 file changed, 9 insertions(+)
>
>--- a/makedumpfile.c
>+++ b/makedumpfile.c
>@@ -4402,6 +4402,9 @@ create_1st_bitmap(void)
>
> 		pfn_start = paddr_to_pfn(phys_start);
> 		pfn_end   = paddr_to_pfn(phys_end);
>+		if (pfn_start > info->max_mapnr)
>+			continue;
>+		pfn_end = MIN(pfn_end, info->max_mapnr);
>
> 		for (pfn = pfn_start; pfn < pfn_end; pfn++) {
> 			set_bit_on_1st_bitmap(pfn);
>@@ -7511,6 +7514,9 @@ exclude_xen3_user_domain(void)
> 		pfn     = paddr_to_pfn(phys_start);
> 		pfn_end = paddr_to_pfn(phys_end);
> 		size    = pfn_end - pfn;
>+		if (pfn > info->max_mapnr)
>+			continue;
>+		pfn_end = MIN(pfn_end, info->max_mapnr);
>
> 		for (j = 0; pfn < pfn_end; pfn++, j++) {
> 			print_progress(PROGRESS_XEN_DOMAIN, j + (size * i),
>@@ -7575,6 +7581,9 @@ exclude_xen4_user_domain(void)
> 		pfn     = paddr_to_pfn(phys_start);
> 		pfn_end = paddr_to_pfn(phys_end);
> 		size    = pfn_end - pfn;
>+		if (pfn > info->max_mapnr)
>+			continue;
>+		pfn_end = MIN(pfn_end, info->max_mapnr);
>
> 		for (j = 0; pfn < pfn_end; pfn++, j++) {
> 			print_progress(PROGRESS_XEN_DOMAIN, j + (size * i),
>
>
>_______________________________________________
>kexec mailing list
>kexec at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/kexec