Re: [PATCH 1/1] fill vdso with syscall32_setup_pages if TIF_IA32 on x86_64

["Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>]

Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
> 
> 
> Serge E. Hallyn wrote:
> > Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
> >> 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