[PATCH 1/1] fill vdso with syscall32_setup_pages if TIF_IA32 on x86_64
Serge E. Hallyn
serue at us.ibm.com
Wed Jan 27 13:10:52 PST 2010
Quoting Oren Laadan (orenl at cs.columbia.edu):
> Serge E. Hallyn wrote:
> > Quoting Oren Laadan (orenl at cs.columbia.edu):
> >> 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
More information about the Containers