[CRIU] Re: [RFC 0/4] Bring ability to multiple c/r of a program

[Cyrill Gorcunov]

On Mon, Jul 23, 2012 at 07:21:28AM +0400, Pavel Emelyanov wrote:
> On 07/20/2012 09:33 PM, Cyrill Gorcunov wrote:
> > Guys, as you know we've a bit of problem c/r'ing program
> > being previously checkpointed, such as
> > 
> >  - resident restorer code get accumulated over c/r sessions
> 
> Yes, this is the problem.
> 
> >  - problem with zero-size VMA rest from clone() stack
> 
> What is it?

If we check out /prot/pid/maps of restored task we will find
a vma with zero size. I found that this vma comes from our
"stask" passed to clone() call. It seems libc has some additional
reference to this vma and when we do munmap in restorer code the
vma stays alive even after, but with zero size.

> > both are addressed in this series. Please review, comments are welcome.
> 
> IMO idea with uuids is not nice. I'd do it the other way:
> 
> 1. We need two restorer.o codes -- one big blob which we have now,
>    the other one small which does only two things (see below)
> 2. Big blob:
>    a. prepares everything it does now except for the sigreturn stuff
>    b. puts sigreturn frame on target task's stack end
>    c. loads the small blob
>    d. jumps into it
> 3. Small blob:
>    It looks like zeroed out page with small portion of code at the
>    beginning which does:
>    a. calls munmap on address somewhere on stack (big blob vma)
>    b. calls sigreturn with sigframe in stack (prepared by big blob)
> 
> With this after restore we have only one vma left which looks like
> tons of zero and several bytes of code. On 2nd restore we can just memcmp
> this VMA and do not re-load it again if it matches.

And how pray tell it's differ from uuid approach? :) We still to
figure out in parasite dumper code that some particular vma remains
from restorer and without _speacial_ markers injected into memory
you simply can't be sure if you don't miss dumping valid code.

	Cyrill