- 16 Sep, 2017 40 commits
-
-
Mike Rapoport authored
The UNIX sockets do not like relative paths. Assuming both lazy-pages daemon and restore use the same opts.work_dir, their working directory full path will be the same. Signed-off-by:
Mike Rapoport <rppt@linux.vnet.ibm.com> Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com>
-
Pavel Tikhomirov authored
https://github.com/xemul/criu/issues/187Signed-off-by:
Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Signed-off-by:
-
Mike Rapoport authored
The remote lazy pages variant can be run as follows: src# criu dump -t <pid> --lazy-pages --port 9876 -D /tmp/1 & src# while ! sudo fuser 9876/tcp ; do sleep 1; done src# scp -r /tmp/1/ dst:/tmp/ dst# criu lazy-pages --page-server --address dst --port 9876 -D /tmp/1 & dst# criu restore --lazy-pages -D /tmp/1 In a nutshell, this implementation of remote lazy pages does the following: - dump collects the process memory into the pipes, transfers non-lazy pages to the images or to the page-server on the restore side. The lazy pages are kept in pipes for later transfer - when the dump creates the page_pipe_bufs, it marks the buffers containing potentially lazy pages with PPB_LAZY - at the dump_finish stage, the dump side starts TCP server that will handle page requests from the restore side - the checkpoint directory is transferred to the restore side - on the restore side lazy-pages daemon is started, it creates UNIX socket to receive uffd's from the restore and a TCP socket to forward page requests to the dump side - restore creates memory mappings and fills the VMAs that cannot be handled by uffd with the contents of the pages*img. - restore registers lazy VMAs with uffd and sends the userfault file descriptors to the lazy-pages daemon - when a #PF occurs, the lazy-pages daemon sends PS_IOV_GET command to the dump side; the command contains PID, the faulting address and amount of pages (always 1 at the moment) - the dump side extracts the requested pages from the pipe and splices them into the TCP socket. - the lazy-pages daemon copies the received pages into the restored process address space Signed-off-by:
-
Mike Rapoport authored
Signed-off-by:
-
Mike Rapoport authored
When appropriate, the lazy pages will no be written to the destination. Instead, a pagemap entry for range of such pages will be marked with 'lazy' flag. Signed-off-by:
-
Mike Rapoport authored
The pages that are mapped to zero_page_pfn are not dumped but information where are they located is required for lazy restore. Note that get_pagemap users presumed that zero pages are not a part of the pagemap and these pages were just silently skipped during memory restore. At the moment I preserve this semantics and force get_pagemap to skip zero pages. Signed-off-by:
-
Mike Rapoport authored
Pagemap now is more friendly to random accesses, enable use of new APIs. Signed-off-by:
Adrian Reber <areber@redhat.com> Signed-off-by:
-
Mike Rapoport authored
Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
Mike Rapoport authored
Signed-off-by:
-
Mike Rapoport authored
Fix CID 163485 (#2 of 2): Dereference null return value (NULL_RETURNS) 7. dereference: Dereferencing a pointer that might be null dest when calling handle_user_fault. Signed-off-by:
-
Mike Rapoport authored
Signed-off-by:
-
Mike Rapoport authored
This will allow to split a ppb so that data residing at specified address will be immediately available Signed-off-by:
-
Mike Rapoport authored
for buffers that contain potentially lazy pages Signed-off-by:
-
Pavel Emelyanov authored
Signed-off-by:
-
Andrew Vagin authored
>>> >>> CID 161312: Error handling issues (NEGATIVE_RETURNS) >>> >>> "task_args->uffd" is passed to a parameter that cannot be negative. Signed-off-by:
Andrew Vagin <avagin@virtuozzo.com> Signed-off-by:
-
Andrew Vagin authored
>>> >>> CID 161322: API usage errors (USE_AFTER_FREE) >>> >>> Calling "close(int)" closes handle "client" which has already been closed. Signed-off-by:
-
Adrian Reber authored
Now that userfaultfd/lazy-pages support is enable all the time, this adds runtime detection of userfaultfd. On a system without the userfaultfd syscall following is printed: uffd daemon: (00.000004) Error (uffd.c:176): lazy-pages: Runtime detection of userfaultfd failed on this system. (00.000024) Error (uffd.c:177): lazy-pages: Processes cannot be lazy-restored on this system. or criu restore (00.457047) 6858: Error (uffd.c:176): lazy-pages: Runtime detection of userfaultfd failed on this system. (00.457049) 6858: Error (uffd.c:177): lazy-pages: Processes cannot be lazy-restored on this system. Signed-off-by:
-
Andrew Vagin authored
Add linux/userfaultfd.h to criu sources. This header is a part of the kernel API and I see nothing wrong to have in the repo. Why we want to do this: * to check that criu works correctly if a kernel doesn't support userfaultfd. * to check compilation of the userfaultfd part in travis-ci. v2: remove UFFD from FEATURES_LIST Acked-by:
-
Mike Rapoport authored
Signed-off-by:
-
Mike Rapoport authored
Signed-off-by:
-
Mike Rapoport authored
Signed-off-by:
-
Mike Rapoport authored
for holding state related to userfaultfd handling Signed-off-by:
-
Mike Rapoport authored
It verifies that amount of collected and transferred pages is consitent and prints a summary Signed-off-by:
-
Mike Rapoport authored
It will handle page fault notifications from userfaultfd Signed-off-by:
-
Mike Rapoport authored
Signed-off-by:
-
Mike Rapoport authored
Signed-off-by:
-
Mike Rapoport authored
so that listenning file descriptor might be used in select/poll Signed-off-by:
-
Mike Rapoport authored
If CONFIG_HAS_UFFD is not defined an attempt to run the lazy pages daemon will result in error message Signed-off-by:
-
Mike Rapoport authored
Signed-off-by:
-
Mike Rapoport authored
The __u64 is 'unsigned long' on Power and 'unsigned long long' on x86_64. Using PRI?64 does not help because, for instance, PRIu64 is 'lu'. According to [1] the solution is to define __SANE_USERSPACE_TYPES__ for Power builds [1] http://thread.gmane.org/gmane.linux.kernel/1425475/focus=1427433Signed-off-by:
-
Mike Rapoport authored
When get_page returns 0, it means that a page is mapped by a vma but it is not found in the pagemap. This happens when a page is a zero page and threofre skipped by dump. Use UFFDIO_ZEROMAP to create a zero page in the restored process address space. Signed-off-by:
-
Mike Rapoport authored
so that it'll be able to handle both UFFDIO_COPY and UFFDIO_ZEROPAGE Signed-off-by:
-
Mike Rapoport authored
The uffd_copied_pages can be incremented in uffd_copy_page function rather than in its callers Signed-off-by:
-
Adrian Reber authored
Most of the UFFD logic was in the function uffd_listen() which was directly called from crtools.c. In preparation for the remote lazy restore most of the code has been moved to separate function for better integration of the network functionality. Signed-off-by:
-
Adrian Reber authored
To better track how many pages have been handled by UFFD a few variables have been made static global to easier access them and to reduce the number of parameters passed around. Signed-off-by:
-
Adrian Reber authored
uffd_listen() is a rather large function and this starts to move code into subfunctions. Signed-off-by:
-
Adrian Reber authored
The variable vma_size was used for early debugging of lazy restore and has no significance now. Signed-off-by:
-
Mike Rapoport authored
Since VDSO pages cannot be lazy, no need to take care of them in lazy-pages daemon. Signed-off-by:
Mike Rapoport <rapoport@il.ibm.com> Signed-off-by:
-
Mike Rapoport authored
VDSO is just a few pages and they can be loaded directly rather than go through userfaultfd to save some complexity on the lazy-pages daemon side. Signed-off-by:
-
Adrian Reber authored
For a lazy restore via userfaultfd the lazy-pages daemon needs to know which pages exist, so that it knows when all pages have finally been migrated so that the restored process has all of its memory. Therefore it needs to know which pages exist and it needs to parse the files in the dump result directory. The existing criu functions are designed to be used by a 'normal' restore and thus a lot of assumptions are made what has to be set up. For the lazy-pages restore the complete 'restore' initialization is not necessary and therefore the criu common code dependencies are minimized with this commit. Signed-off-by:
-
