almost ckpt-v19-rc3

almost ckpt-v19-rc3

[Oren Laadan]

Hi,

I pushed ckpt-v19-rc2.9 which has all patches (*) inside and folded
to a clean set. It passes basic tests here.

(*) except the recent fix to s390 restart-blocks

Next step is to rebase it to a recent kernel and push again as v19-rc3.

Please give it a try, see if I missed anything.

Also, for s390 and powerpc, the checkpoint_thread() is empty.
I think they should at least run a may_checkpoint_thread()
(like in x86) to check the thread is suitable for checkpoint
when checkpointing, and to restore thread flags (TIF..) if
necessary on restart.

The user-cr is already at ckpt-v19-rc3.

Thanks,

Oren.

Re: almost ckpt-v19-rc3

[Serge E. Hallyn]

Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
> Hi,
> 
> I pushed ckpt-v19-rc2.9 which has all patches (*) inside and folded
> to a clean set. It passes basic tests here.
> 
> (*) except the recent fix to s390 restart-blocks
> 
> Next step is to rebase it to a recent kernel and push again as v19-rc3.
> 
> Please give it a try, see if I missed anything.
> 
> Also, for s390 and powerpc, the checkpoint_thread() is empty.
> I think they should at least run a may_checkpoint_thread()
> (like in x86) to check the thread is suitable for checkpoint
> when checkpointing, and to restore thread flags (TIF..) if
> necessary on restart.

Yeah I was going to add a check for TIF_31BIT in there - just bc
I can't get rhel5.3 to compile 31-bit binaries doesn't mean noone
else can  :)

> The user-cr is already at ckpt-v19-rc3.
> 
> Thanks,
> 
> Oren.

Re: almost ckpt-v19-rc3

[Serge E. Hallyn]

Quoting Oren Laadan (orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org):
> Hi,
> 
> I pushed ckpt-v19-rc2.9 which has all patches (*) inside and folded
> to a clean set. It passes basic tests here.
> 
> (*) except the recent fix to s390 restart-blocks
> 
> Next step is to rebase it to a recent kernel and push again as v19-rc3.
> 
> Please give it a try, see if I missed anything.

Doh, actually, there is still a problem with IA32 tasks on x86-64:
if COMPAT_VDSO=y then the do_munmap() in destroy_mm() fails bc
vma->end > TASK_SIZE (vma->start == TASK_SIZE).  The reason this
doesn't cause a problem on x86-32, actually, is only bc the vdso
page doesn't seem to be in the list of vma's at all!  At least a
printk in destroy_mm() (a few days ago) never showed it running
across the vdso page.

So, perhaps the way to simultaneously solve both this and the unmaps
of 64-bit mappings in /bin/restart_64 after it has switched to
TIF_IA32 is to move destroy_mm() to a proper helper in mm/mmap.c,
and have it tell do_munmap() to avoid the TASK_SIZE check.

-serge