Cool ! So what do we have working now for 64 bit kernel (for 32 bit kernel we know it works...): 'restart' checkpointed program program ---------------------------------------- 64bit 64bit -> works 32bit 32bit -> works 64bit 32bit -> ????? Does it make sense to allow the opposite transition: 'restart' starts as a 32bit and becomes a 64bit after it restores the state from the image ? And what about if you checkpoint on a 32 bit kernel and try to restart on a 64 bit kernel, and vice versa ? (in both cases, the program of course is 32bit, and we can assume same physical host for now). Oren. On Wed, 27 Jan 2010, Serge E. Hallyn wrote: > arch_setup_additional_pages() on x86_64 fills in a 64-bit > vdso page. > > With this patch, restart of 32-bit tasks (both self- and external > checkpoints) on x86-64 succeeds. > > Signed-off-by: Serge E. Hallyn <serue@xxxxxxxxxx> > --- > mm/mmap.c | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/mm/mmap.c b/mm/mmap.c > index 1759a7f..e3d4178 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -2324,6 +2324,10 @@ int special_mapping_restore(struct ckpt_ctx *ctx, > * Even that, is very basic - call arch_setup_additional_pages > * requiring the same mapping (start address) as before. > */ > +#ifdef CONFIG_X86_64 && CONFIG_COMPAT > + if (test_thread_flag(TIF_IA32)) > + return syscall32_setup_pages(NULL, h->vm_start, 0); > +#endif > return arch_setup_additional_pages(NULL, h->vm_start, 0); > } > #else /* !CONFIG_CHECKPOINT */ > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
