Line 1: |
Line 1: |
− | draft
| + | === Overview === |
| + | |
| + | '''vDSO''' stands for [http://man7.org/linux/man-pages/man7/vdso.7.html ''virtual dynamic shared object''] and basically is a shared library exported by kernel into every userspace program. It usually exports a few frequently used functions (such as gettimeofday, getcpu and etc) and userspace applications don't call them directly but make use of '''libc''' instead. |
| + | |
| + | === A problem === |
| + | |
| + | While the kernel guarantees backwards compatibility (i.e. helper functions won't suddenly disappear), the internal structure of the '''vDSO''' itself may vary. Userspace programs won't notice such changes but it brings a huge problem to CRIU. The '''vDSO''' structure is highly coupled with the kernel internals. If an application is being migrated to a new kernel release (with a brand new '''vDSO''') the old '''vDSO''' (which is stored in the application's memory) is no longer usable. |
| + | |
| + | === Calls proxification === |
| + | |
| + | 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 |
| + | # 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) |
| + | |
| + | After that an restored application can continue using original '''vDSO''' helpers without problems. |
| + | |
| + | 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. |
| + | |
| + | [[Category: Under the hood]] |