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

[Pavel Emelyanov]

On 07/23/2012 10:35 AM, Cyrill Gorcunov wrote:
> On Mon, Jul 23, 2012 at 10:26:20AM +0400, Pavel Emelyanov wrote:
>> 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.
> 
> Yes, I've tried that at friday. Continue trying...
> 
>>>> 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.
> 
> Again, Pavel, you're pointing "On 2nd restore we can just memcmp
> this VMA and do not re-load it again if it matches" this is bloody
> wrong. The user might have some previously checkpointer program
> running, then he recompiles the crtools and here are two variants
> 
>  1) we write all this restorer code in assembly, which means we
>     _always_ generate same code for all program versions

We _always_ generate the same code for the 2nd restorer for all program
versions.

>  2) we use C, thus crtools instructions might have been changed
>     between builds
> 
> in either way it's pretty fragile to "memcmp" over restorer blob
> for instructions match.
> 
> With uuid approach crtools need to meet at least two conditions
> on restorer blob which can't be met without special construction
> of such vma area
> 
>  1) VMA must be executable
>  2) VMA must _start_ with uuid and its sha1 hash
> 
> these conditions will never met in real programs.

Please, prove.

> This makes me sure that uuid approach is a way better than complex two
> blobs scheme.
> 
> 	Cyrill
> .
>