Oh ... maybe that's what why checkpoint fails on my experimental x86-64 port: it worked well on 2.6.31 but fails with "bad address" on 2.6.32. It may be related to a change between 2.6.31 and 2.6.32 in the arguments to follow_page(), see commit: mm: FOLL_DUMP replace FOLL_ANON 8e4b9a60718970bbc02dfd3abd0b956ab65af231 ? Oren. Nathan Lynch wrote: > On Wed, 2009-12-02 at 00:23 -0500, Oren Laadan wrote: >> I put together ckpt-v19-rc2 (kernel and user) > > I'm not sure yet whether this is a regression, but checkpoint seems to > be unable to handle file mappings that extend past the end of the file. > I noticed this with Fedora 11 userspace on powerpc (ld.so sometimes maps > libraries this way). I did not see this failure with a v19-rc1-based > kernel I tested earlier this week, but I haven't retested with that yet. > > Here's an example - 8K mapping of a 4K file: > > # stat -c%s /tmp/myfile > 4096 > > # grep myfile /proc/5164/maps > f7e2b000-f7e2d000 r--p 00000000 08:06 5103709 /tmp/myfile > > # checkpoint 5164 > /tmp/mmap.ckpt > checkpoint: Bad address > > When we try to follow the mapping past the end of the file, we get > VM_FAULT_SIGBUS from handle_mm_fault(); the stack trace from debugging > code I added is: > > .__get_dirty_page+0x4c/0x164 (unreliable) > .checkpoint_memory_contents+0x134/0x5a4 > .private_vma_checkpoint+0xf4/0x120 > .filemap_checkpoint+0x198/0x1d0 > .checkpoint_mm+0x3c4/0x4fc > .checkpoint_obj+0x17c/0x1d0 > .checkpoint_obj_mm+0x50/0x88 > .checkpoint_task+0x710/0xaa0 > .do_checkpoint+0x9c0/0xb24 > .SyS_checkpoint+0xd0/0x11c > > Attached is a testcase. > > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
