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

[Pavel Emelyanov]

On 07/23/2012 10:07 AM, Cyrill Gorcunov wrote:
> 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.

Libc cannot reference VMA object in kernel. Need to find out why it's there.

>>> 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.

My markers are not special, but the code we're about to inject.

> 	Cyrill
> .
>