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

[Cyrill Gorcunov]

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

 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. This makes
me sure that uuid approach is a way better than complex two
blobs scheme.

	Cyrill