[Devel] Re: [PATCH 3/7] make CONFIG_CHECKPOINT dependonCONFIG_CHECKPOINT_SUPPORT

[Oren Laadan]

Serge E. Hallyn wrote:
> Quoting Oren Laadan (orenl at cs.columbia.edu):
>> Hi Gordon,
>>
>> Serge E. Hallyn wrote:
>>> Quoting Ralph-Gordon Paul (Ralph-Gordon.Paul at uni-duesseldorf.de):
>>>> Ah okay sorry, i used this version: http://git.ncl.cs.columbia.edu/?p=linux-cr.git;a=shortlog;h=refs/heads/ckpt-v15
>>>>
>>>> Is this the official place to download the up to date version ?
>> ckpt-v15 branch per-se is a snapshot of the patchset as it was released.
>>
>> ckpt-v15-dev is the development branch that is based on ckpt-v15, and is
>> probably what you want to use.
>>
>> the userspace utilities are in the matching v15-dev in 'user-cr.git'.
>>
>>>> -Gordon
>>> Hi Gordon,
>>>
>>> yes, and you were right about needing compat vdso.  Sorry about the
>>> inconvenience (since it was my patch).  I was just saying that since
>>> Oren has added the underlying code for moving vdso around, there is no
>>> reason why we shouldn't complete that support (with 1 line of code)
>>> allowing us to remove the dependency on CONFIG_COMPAT_VDSO.
>> True, no need to keep that dependency. Will remove.
>>
>> Note, however, that we still don't handle the case where the contents of
>> the VDSO page(s) differ between checkpoint and restart time...  So it's
>> on the todo list to at least detect that the format changed.
> 
> sigh - yeah, and we still haven't decided how to cleanly solve that,
> have we...  (apart from some arch-specific memcmp template/map that
> compares the code and not data...)

Heh .. I thought we outlined a suitable solution:

* On checkpoint, save the contents of the VDSO page(s), or their hash,
  but not including any dynamic data exported by the kernel. The VDSO
  contents themselves should be a shared object.

* On restart, compare the contents, or their hash, with the local
  kenrel; If there is a match -- all well. If not - need to provide
  some compatibility code in place of the original VDSO.

The gory details .. oh well ...

Oren.

_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers