32bit tasks C/R - Revision history

Dsafonov: Done upstream: Continue removing TIF_IA32 from uprobes & Oprofile

2023-05-23T19:36:45Z

Done upstream: Continue removing TIF_IA32 from uprobes & Oprofile

Dsafonov: /* Needs to be done (TODO) */ autofs is fixed by Stas, AFAIK

2017-12-05T13:43:31Z

Needs to be done (TODO): autofs is fixed by Stas, AFAIK

Rppt at 08:45, 28 September 2017

2017-09-28T08:45:21Z

Xemul: Development finished

2017-08-18T13:46:13Z

Development finished

Dsafonov: Fixes for older kenels (vz-related) - done

2017-05-18T18:50:25Z

Fixes for older kenels (vz-related) - done

Dsafonov: /* List of failed tests */ Remove tests fixed in criu-dev

2017-05-05T10:00:45Z

List of failed tests: Remove tests fixed in criu-dev

Dsafonov: Add a note about mixed-bitness applications

2017-05-02T19:24:28Z

Add a note about mixed-bitness applications

Dsafonov: /* Needs to be done (TODO) */ kerndat check posted, vdso helper segfault fixed

2017-04-21T20:37:19Z

Needs to be done (TODO): kerndat check posted, vdso helper segfault fixed

Dsafonov: /* List of failed tests */ vdso trampolines fix applied to criu-dev

2017-03-16T12:09:33Z

List of failed tests: vdso trampolines fix applied to criu-dev

Dsafonov: mmap() bug: fixed, but kerndat need some care

2017-03-14T12:26:03Z

mmap() bug: fixed, but kerndat need some care

@@ Line 92: / Line 92: @@
 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 ==

@@ Line 78: / Line 78: @@
 == Needs to be done (TODO) ==
 === Kernel patch for vsyscall page ===
@@ Line 97: / Line 86: @@
 At this moment we'll support only compat ia32 applications, attempt to dump x32 compat binary should result in error.
 == External links ==

@@ Line 99: / Line 99: @@
 == 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‏‎]]

← Older revision		Revision as of 13:46, 18 August 2017
Line 101:		Line 101:
	* [https://github.com/xemul/criu/issues/43 github issue]		* [https://github.com/xemul/criu/issues/43 github issue]

−	~~[[Category: Development]]~~
	[[Category: Under the hood‏‎]]		[[Category: Under the hood‏‎]]

@@ Line 89: / Line 89: @@
 | autofs || test's bug - hangs without C/R
 |}
 === Kernel patch for vsyscall page ===

@@ Line 86: / Line 86: @@
 ! Name
 ! Fail reason
 |-
 | autofs || test's bug - hangs without C/R
 |}

@@ Line 18: / Line 18: @@
 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.
 == Approaches to C/R compatible applications ==

← Older revision		Revision as of 20:37, 21 April 2017
Line 68:		Line 68:

	== Needs to be done (TODO) ==		== Needs to be done (TODO) ==
−
−	~~=== Kerndat test: check presence of the bug with mmaping over 4Gb ===~~
−
−	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.
−
−	~~See [[Upstream kernel commits]], the bug is fixed in linux-next, but the kerndat criu test should be reworked to check presence of this bug, not only arch_prctl() for 32-bit vdso.~~
−
−	~~=== Issue with compat vdso helper ===~~
−	~~Rarely it segfaults: [https://github.com/xemul/criu/issues/290 issue], [https://github.com/xemul/criu/issues/273 reproduce].~~
−	~~Presumably, because of using syscall() and memcpy() from Glibc, instead of raw pie-helpers at the moment of unmapped vdso/vvar vmas.~~
−	~~Hard to reproduce.~~

	=== List of failed tests ===		=== List of failed tests ===

@@ Line 93: / Line 93: @@
 |-
 | vdso01 || need to add 32-bit vDSO symbols: __kernel_* (and check them with handlers in test)
 |}

@@ Line 69: / Line 69: @@
 == Needs to be done (TODO) ==
-=== Bug with mmaping over 4Gb ===
+=== Kerndat test: check presence of the bug with mmaping over 4Gb ===
 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.
-See [[Upstream kernel commits]]. 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).
+See [[Upstream kernel commits]], the bug is fixed in linux-next, but the kerndat criu test should be reworked to check presence of this bug, not only arch_prctl() for 32-bit vdso.
 === Issue with compat vdso helper ===
 Rarely it segfaults: [https://github.com/xemul/criu/issues/290 issue], [https://github.com/xemul/criu/issues/273 reproduce].
-Presumply, because of using syscall() and memcpy() from Glibc, instead of raw pie-helpers.
+Presumably, because of using syscall() and memcpy() from Glibc, instead of raw pie-helpers at the moment of unmapped vdso/vvar vmas.
 Hard to reproduce.
@@ Line 94: / Line 94: @@
 | vdso01 || need to add 32-bit vDSO symbols: __kernel_* (and check them with handlers in test)
 |-
-| vdso01 || fails at fault-inject trampoline testing: correct jump trampolines [https://lists.openvz.org/pipermail/criu/2017-March/036187.html Fixed]
+| vdso01 || fails at fault-inject trampoline testing: correct jump trampolines [https://lists.openvz.org/pipermail/criu/2017-March/036187.html Fixed in this set]
 |}