| Line 69: |
Line 69: |
| | == Needs to be done (TODO) == | | == 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. | | 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 === | | === Issue with compat vdso helper === |
| | Rarely it segfaults: [https://github.com/xemul/criu/issues/290 issue], [https://github.com/xemul/criu/issues/273 reproduce]. | | 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. | | Hard to reproduce. |
| | | | |
| Line 94: |
Line 94: |
| | | vdso01 || need to add 32-bit vDSO symbols: __kernel_* (and check them with handlers in test) | | | 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] |
| | |} | | |} |
| | | | |