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

[Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>]

Serge E. Hallyn wrote:
> Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
>>
>> Serge E. Hallyn wrote:
>>> 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		-> ?????
> 
> s/?????/Rejected/
> 
> CKPT_ARCH_ID is of course different for X86_32 than X86_64, so
> we refuse restart in restore_read_header().
> 
> -serge
> 

lol ... that's actually funny !

Anyway, in light of the IRC discussions, here are the cases again:


original	original	restart		target
program		kernel		program		kernel
--------	---------	--------	--------
64 bit		64 bit		64 bit		64 bit	  [0] works

32 bit		32 bit		32 bit		32 bit	  [0] works
32 bit		64 bit		32 bit		64 bit	  [0] works

32 bit		32 bit		32 bit		64 bit	  [1]
32 bit		64 bit		32 bit		32 bit	  [1]

32 bit		any		64 bit		64 bit	  [2]
64 bit		64 bit		32 bit		64 bit	  [2]

[0] The first 3 cases are "homogeneous", with conditions equal at
checkpoint and restart. AFAIK, they work.

[1] The next two cases consider 32 bit program, and vary only the
environment - the kernel may change from 32 to 64 or back. We want
them to work.

IIUC, your comment above means that they don't work because the
CKPT_ARCH_ID is a mismatch. The fix should be trivial - either
make 'restart' modify it, or make the kernel tolerate it.

[2] The last two cases consider the case when the restart program
itself has different bit-ness than the checkpointed program (and
transition may occur in either direction). While lower priority,
we would like this to work, too.

The question is whether the transition 64 -> 32 (or 32 ->64) from
the 'restart' program to the restarting task should happen in the
kernel as part of sys_restart(), or in user space using an execve()
syscall before calling sys_restart().

Doing so in user space is not trivial when threads are involved,
since the exec must then happen before the creation of threads (or
it will kill them). This will complicate the implementation of the
MakeForest() algorithm which relies on all all descendents seeing
the same data structures.

Doing so in kernel should have been easy in theory, but in practice
so far it isn't working; and it may be frowned upon by kernel people
(allowing such transition not in exec).

Oren.