[CRIU] Dealing with VDSO remap

[Laurent Dufour]

On 19/03/2015 16:37, Cyrill Gorcunov wrote:
> On Thu, Mar 19, 2015 at 06:28:24PM +0300, Pavel Emelyanov wrote:
>> On 03/06/2015 05:15 PM, Laurent Dufour wrote:
>>
>>> If not, is there a plan in the CRIU project to to deal with that, other
>>> than by hacking the kernel to update its reference at restart time ?
>>
>> BTW, I've just remembered that there's a way to overcome this issue
>> by mapping a fake VDSO into task which would contain plan calls to
>> the respective system calls.
>>
>> It's not perfect solution, but I think it can be used as temporary
>> one until the VDSO remapping is resolved in the kernel.
>>
>> What do you think?
> 
> If I understand correctly the problem is not in the vDSO as its
> own but rather an addressing problem. If on restore the base
> vdso address differs from one saved in image and the kernel
> still carry a reference to the former vdso, we might get a
> situation where memory map from image get intersected with
> vdso address kernel keeps in own guts, so nothing would help
> here until the kernel patched.

You're right Cyrill, a kernel patch is required here. I wrote it and I'm
about to send it upstream.

However, there is still a window that cannot be addressed: if a process
is checkpointed while it is handling a signal, then the checkpointed
stack will contain a reference to the former vDSO's sigreturn service. I
guess at restart time, there is a major chance that the restarted
process is core dumping when returning from the signal handler :(

I can't see any way to address that.
May be someone have a great idea ?