The old and new address parameters passed to the mremap system
call must be page size aligned. On AArch64, the page size can
only be correctly determined at run time. This fixes the following
errors for CRIU on AArch64 kernels with CONFIG_ARM64_64K_PAGES=y.
call mremap(0x3ffb7d50000, 8192, 8192, MAYMOVE | FIXED, 0x2a000)
Error (rst-malloc.c:201): Can't mremap rst mem: Invalid argument
call mremap(0x3ffb7d90000, 8192, 8192, MAYMOVE | FIXED, 0x32000)
Error (rst-malloc.c:201): Can't mremap rst mem: Invalid argument
Signed-off-by: Christopher Covington <cov@codeaurora.org>
Acked-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
After we got the total remapable rst memory size, we no longer
can allocate from it, otherwise the bootstrap area will not
have enough size.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Remove whitespace at EOL (found by git grep ' $')
To people using vim, I'd suggest adding the following code to ~/.vimrc:
let c_space_errors = 1
highlight FormatError ctermbg=darkred guibg=darkred
match FormatError /\s\+$\|\ \+\t\|\%80v.\|\ \{8\}/
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
On restore we need differetn types of memory allocation.
Here's an engine that tries to generalize them all. The
main difference is in how the buffer with objects is being
grown up.
There are 3 types of memory allocations:
1. shared memory -- objects, that will be used by all criu
children, but will not reach the restorer
2. shared remapable -- the same, but restorer would need
access to them, i.e. -- buffer with objects will get
remapped into restorer
3. private -- the same, but allocatedby each task for itself
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
