[PATCH v3 1/2] Generic handling of multi-page exclusions

[HATAYAMA Daisuke]

From: HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com>
Subject: Re: [PATCH v3 1/2] Generic handling of multi-page exclusions
Date: Wed, 14 May 2014 19:37:23 +0900

> From: Atsushi Kumagai <kumagai-atsushi at mxc.nes.nec.co.jp>
> Subject: RE: [PATCH v3 1/2] Generic handling of multi-page exclusions
> Date: Wed, 14 May 2014 07:54:17 +0000
> 
>> Hello Petr,
>> 
>>>When multiple pages are excluded from the dump, store the extents in
>>>struct cycle and check if anything is still pending on the next invocation
>>>of __exclude_unnecessary_pages. This assumes that:
>>>
>>>  1. after __exclude_unnecessary_pages is called for a struct mem_map_data
>>>     that extends beyond the current cycle, it is not called again during
>>>     that cycle,
>>>  2. in the next cycle, __exclude_unnecessary_pages is not called before
>>>     this final struct mem_map_data.
>>>
>>>Both assumptions are met if struct mem_map_data segments:
>>>
>>>  1. do not overlap,
>>>  2. are sorted by physical address in ascending order.
>> 
>> In ELF case, write_elf_pages_cyclic() processes PT_LOAD entries from
>> PT_LOAD(0), this can break both assumptions unluckily.
>> Actually this patch doesn't work on my machine:
>> 
>> LOAD (0)
>>   phys_start : 1000000
>>   phys_end   : 182f000
>>   virt_start : ffffffff81000000
>>   virt_end   : ffffffff8182f000
>> LOAD (1)
>>   phys_start : 1000
>>   phys_end   : 9b400
>>   virt_start : ffff810000001000
>>   virt_end   : ffff81000009b400
>> LOAD (2)
>>   phys_start : 100000
>>   phys_end   : 27000000
>>   virt_start : ffff810000100000
>>   virt_end   : ffff810027000000
>> LOAD (3)
>>   phys_start : 37000000
>>   phys_end   : cff70000
>>   virt_start : ffff810037000000
>>   virt_end   : ffff8100cff70000
>> LOAD (4)
>>   phys_start : 100000000
>>   phys_end   : 170000000
>>   virt_start : ffff810100000000
>>   virt_end   : ffff810170000000
>> 
>> 
>> PT_LOAD(2) includes PT_LOAD(0) and there physical addresses aren't sorted.
>> 
>> If there is the only "sort issue", it may easy to fix it with a new iterator
>> like "for_each_pt_load()", it iterates PT_LOAD entries in ascending order
>> by physical address.
>> However, I don't have a good idea to solve the overlap issue now...
>> 
> 
> Is it enough to merge them? Prepare a modified version of PTLOAD list
> and refer to it in actual processing. I think this also leads to
> cleaning up readpage_elf() that addresses some overapping memory map
> issue on ia64.
> 

I'm saying this because I don't find anywhere virt_start or virt_end
is used. We look up page table to convert virtual address to physical
address, not PT_LOAD entries.

--
Thanks.
HATAYAMA, Daisuke