(2013/12/03 0:27), Vivek Goyal wrote: > On Thu, Nov 28, 2013 at 05:48:02PM +0900, HATAYAMA Daisuke wrote: >> Hello Vivek, >> >> Here is a patch set for mmap failure for /proc/vmcore. >> Could you try to use this on the problematic system? >> >> This patch doesn't copy partial pages to the 2nd kernel, only prepares >> vmcore objects for respective partial pages to invoke remap_pfn_range() >> for individual partial pages. > > Hi Hatayama, > > Thanks for the patch. Ok, I see that partial pages will be put in a separate > call to remap_oldmem_pfn_range() and this time it should succeed. > > I am wondering what do you think about your old approach of copying > only relevant old memory to a new kernel page in new kernel. I kind > of feel little uncomfortable with the idea of rounding down start > and roudning up end to page size boundaries and then accessing the > full page using oldmem interface. A safer approach might be to allocate > page in new kernel, read *only* those bytes as reported by elf header > and fill rest of the page with zeros. > > Thanks > Vivek > Even if copying partial pages into the 2nd kernel, we need to use ioremap() once on them, and I think the ioremap() is exactly similar to remap_pfn_range() for a single page. There seems no difference on safeness between them. Also, current /proc/vmcore shows user-land tools a shape with holes not filled with zeros both in case of read() and in case of mmap(). If we adapt copying one without reading data in holes, shape of /proc/vmcore gets changed again. -- Thanks. HATAYAMA, Daisuke
