105
edits
Changes
a bit specify what's structure of vdso
To solve this problem CRIU does that named call proxification, where all functions from the original '''vDSO''' code are redirected to a new one provided by the kernel where application is restored. This done in a several steps on restore:
To solve this problem CRIU does that named call proxification, where all functions from the original '''vDSO''' code are redirected to a new one provided by the kernel where application is restored. This done in a several steps on restore:
# Scan runtime environment for current '''vDSO''' and parse its structure
# Scan runtime environment for current '''vDSO''' and parse its structure (size, sections, symbols, etc)
# On restore of dumped '''vDSO''' memory area we patch function entry points so that they are redirected to current '''vDSO''' (for x86 architecture is simply a <code>jmp</code> instruction)
# On restore of dumped '''vDSO''' memory area we patch function entry points so that they are redirected to current '''vDSO''' (for x86 architecture is simply a <code>jmp</code> instruction)
In case if an application is dumped and restored on same kernel CRIU detects that '''vDSO''' structure has not be changed and doesn't use calls proxification.
In case if an application is dumped and restored on same kernel CRIU detects that '''vDSO''' structure has not be changed and doesn't use calls proxification.
=== Unsolved proxification problems ===
# If an application in very unlikely case is Checkpointed over first bytes of vdso entry ''and'' vdso is different on the destination migration node, those might be the bytes that are being patched during proxification. If it's on vdso just after those entry-bytes, the stale data from vvar is taken (might be just fine afterall).
[[Category: Under the hood]]
[[Category: Under the hood]]