[PATCH v3 1/2] Generic handling of multi-page exclusions
d.hatayama at jp.fujitsu.com
Wed May 14 03:54:28 PDT 2014
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.
More information about the kexec