Serge E. Hallyn wrote: > Quoting Oren Laadan ([email protected]): >> >> Serge E. Hallyn wrote: >>> Quoting Oren Laadan ([email protected]): >>>> 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 -> ????? >>> Actually the other way around works - /bin/restart_32 < 64bit.out >>> works just fine. /bin/restart_64 < 32bit.out does not. The reason >>> is that destroy_mm() ends up calling do_munmap on a 64-bit mapping >>> after the switch to 32-bit had been made, and it refuses bc >>> vma->vm_start > TASK_SIZE. >>> >>> Perhaps getting it to work will be as simple as temporarily switching >>> back to 64-bit during destroy_mm(). >> Interesting, I didn't think about it. >> >> So yes, switching temporarily should work. An alternative we can >> do the call destroy_mm() earlier, as it may suit us. >> >>>> 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). >>> I have no hw right now where I could test such a thing. Do you? >>> >> Couldn't you use the same machine you are using - just reboot it >> between checkpoint and restart with a 32bit kernel ... ? > > maybe - but i'm borrowing this machine (with no phys access) so don't > want to get too risky :) > > can give it a shot i guess >
Or you can run the 32bit kernel inside a VM on that machine... _______________________________________________ Containers mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list [email protected] https://openvz.org/mailman/listinfo/devel
