105
edits
Changes
Jump to navigation
Jump to search
Line 18:
Line 18: + + + + + + + + + + Line 68:
Line 78: + + + + Line 73:
Line 87: − + − − As 32-bit application is restored from 64-bit CRIU, some task's properties that were filled on <code>exec()</code> are left, which is quite unusual for 32-bit task. One of the things, left from 64-bit binary is precalculated <code>mmap_base</code> which is used to find task's top/bottom address limit during <code>mmap()</code> syscall. That means that compat <code>sys_mmap()</code> may map page over 4Gb address and return 4-byte pointer to low bytes of address. Looks like no one has used compatible mmap in 64-bit binary. Results in broken mmap in restored 32-bit application, which can map vma over 4Gb. − − Patches to fix this bug at this moment were posted on lkml, but not yet accepted. See [[Upstream kernel commits]]. If they will not go to v4.9-stable, the kerndat test for 32-bit C/R will be reworked to check if the bug present in kernel (which is not nice thing, but ok). − − === 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 − |- − | sse00 − | rowspan="4" | [https://lists.openvz.org/pipermail/criu/2017-February/035638.html fixed by] − |- − | sse20 − |- − | fpu00 − |- − | mmx00 − |- − | 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 − |- − | fpu01 || no ia32 version − |- − | vdso01 || no ia32 version − |} − − === 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). − − === Fault-inject test for vDSO trampolines === − Should ensure that they work. Need to be done for both native/compat C/R.+ − + − === Kernel patch for vsyscall page ===+ − − That's emulated page, not a vma - affects only in /proc/<pid>/maps for restored process. Depends on !TIF_IA32 && !TIF_X32 - Andy got patches for disabling the emulation on per-pid basics, for now I ran tests with <code>vsyscall=none</code> boot parameter because zdtm.py checks maps before/after C/R. − + − [[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 ===
That's emulated page, not a vma - affects only in /proc/<pid>/maps for restored process. Depends on !TIF_IA32 && !TIF_X32 - Andy got patches for disabling the emulation on per-pid basics, for now I ran tests with <code>vsyscall=none</code> boot parameter because zdtm.py checks maps before/after C/R.
=== Error dump on x32-bit app dumping ===
=== Error dump on x32-bit app dumping ===
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.
=== Bug with mmaping over 4Gb ===
=== 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]]