105
edits
Changes
Jump to navigation
Jump to search
Line 18:
Line 18: + + + + + + + + + + Line 68:
Line 78: − − === List of failed tests === − − The table is being kept up-to-date by [[User:Dsafonov|Dsafonov]] with latest kernel/CRIU patches in his environment, some of which may be yet not in tree or even yet not sent. − − {| class="wikitable" − ! Name − ! Fail reason − |- − | futex-rl || sys_get_robust_list() should be compat syscall for 32-bit tasks: kernel keeps two different lists: <code>robust_list</code> and <code>compat_robust_list</code> in <code>task_struct</code> − |- − | autofs || test's bug - hangs without C/R − |- − | vdso01 || need to add 32-bit vDSO symbols: __kernel_* (and check them with handlers in test) − |} − − === Fixes for older kernels === − − For kernels with backported mainline patches for 32-bit C/R (like vzkernel) there are a couple of things to do like different sizes of vdso/vvar (or vvar may not be even present). Line 95:
Line 86: + + + + + + − + − [[Category: Development]]
→Needs to be done (TODO): autofs is fixed by Stas, AFAIK
From the Linux kernel's point of view, applications differ by values set during exec of application such as <code>mmap_base</code> or thread info flags <code>TIF_ADDR32</code>/<code>TIF_IA32</code>/<code>TIF_X32</code>.
From the Linux kernel's point of view, applications differ by values set during exec of application such as <code>mmap_base</code> or thread info flags <code>TIF_ADDR32</code>/<code>TIF_IA32</code>/<code>TIF_X32</code>.
Both native and compat applications can do 32 or 64-bit syscalls.
Both native and compat applications can do 32 or 64-bit syscalls.
== Mixed-bitness applications ==
That's entirely possible with current kernel ABI to create mixed-bitness applications, which may be ''very'' entangled.
For example, one could set ''both'' 32-bit and 64-bit robust futex list pointers.
Or one can create multi-threaded application where some threads are executing 32-bit code, some 64-bit code.
If we ever meet application of such mixed-bitness kind, the support may be added to CRIU quite easily, but it should be done under some compile-time config as it'll add more syscalls to usual C/R where they aren't needed.
At this moment there is no plans to add such support and it's quite unlikely that we'll find such application in real world (non-syntetic test).
== Approaches to C/R compatible applications ==
== Approaches to C/R compatible applications ==
== Needs to be done (TODO) ==
== Needs to be done (TODO) ==
=== Kernel patch for vsyscall page ===
=== Kernel patch for vsyscall page ===
At this moment we'll support only compat ia32 applications, attempt to dump x32 compat binary should result in error.
At this moment we'll support only compat ia32 applications, attempt to dump x32 compat binary should result in error.
=== Continue removing TIF_IA32 from uprobes & Oprofile ===
This flag should be gone as it's suggested by Andy & Oleg.
There is quite lot of work to make kernel work without it, but small gain:
the restored ia32 process will be traced by uprobes/oprofile and stuff like that.
== External links ==
== External links ==
* [https://github.com/xemul/criu/issues/43 github issue]
* [https://github.com/checkpoint-restore/criu/issues/43 github issue]
[[Category: Under the hood]]
[[Category: Under the hood]]