From: HATAYAMA Daisuke <d.hatayama@xxxxxxxxxxxxxx> 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
