- 16 Sep, 2017 40 commits
-
-
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 <rppt@linux.vnet.ibm.com> Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com>
-
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:
-
Adrian Reber authored
Signed-off-by:
-
Adrian Reber authored
This is a first try to include userfaultfd with criu. Right now it still requires a "normal" checkpoint. After checkpointing the application it can be restored with the help of userfaultfd. All restored pages with MAP_ANONYMOUS and MAP_PRIVATE set are marked as being handled by userfaultfd. As soon as the process is restored it blocks on the first memory access and waits for pages being transferred by userfaultfd. To handle the required pages a new criu command has been added. For a userfaultfd supported restore the first step is to start the 'lazy-pages' server: criu lazy-pages -v4 -D /tmp/3/ --address /tmp/userfault.socket This waits on a unix domain socket (defined using the --address option) to receive a userfaultfd file descriptor from a '--lazy-pages' enabled 'criu restore': criu restore -D /tmp/3 -j -v4 --lazy-pages \ --address /tmp/userfault.socket In the first step the VDSO pages are pushed from the lazy-pages server into the restored process. After that the lazy-pages server waits on the UFFD FD for a UFFD requested page. If there are no requests received during a period of 5 seconds the lazy-pages server switches into a mode where the remaining, non-transferred pages are copied into the destination process. After all remaining pages have been copied the lazy-pages server exits. The first page that usually is requested is a VDSO page. The process currently used for restoring has two VDSO pages, but only one is requested via userfaultfd. In the second part where the remaining pages are copied into the process, the second VDSO page is also copied into the process as it has not been requested previously. Unfortunately, even as this page has not been requested before, it is not accepted by userfaultfd. EINVAL is returned. The reason for EINVAL is not understood and therefore the VDSO pages are copied first into the process, then switching to request mode and copying the pages which are requested via userfaultfd. To decide at which point the VDSO pages can be copied into the process, the lazy-pages server is currently waiting for the first page requested via userfaultfd. This is one of the VDSO pages. To not copy a page a second time, which is unnecessary and not possible, there is now a check to see if the page has been transferred previously. The use case to use usefaultfd with a checkpointed process on a remote machine will probably benefit from the current work related to image-cache and image-proxy. For the final implementation it would be nice to have a restore running in uffd mode on one system which requests the memory pages over the network from another system which is running 'criu checkpoint' also in uffd mode. This way the pages need to be copied only 'once' from the checkpoint process to the uffd restore process. TODO: * Contains still many debug outputs which need to be cleaned up. * Maybe transfer the dump directory FD also via unix domain sockets so that the 'uffd'/'lazy-pages' server can keep running without the need to specify the dump directory with '-D' * Keep the lazy-pages server running after all pages have been transferred and start waiting for new connections to serve. * Resurrect the non-cooperative patch set, as once the restored task fork()'s or calls mremap() the whole thing becomes broken. * Figure out if current VDSO handling is correct. * Figure out when and how zero pages need to be inserted via uffd. v2: * provide option '--lazy-pages' to enable uffd style restore * use send_fd()/recv_fd() provided by criu (instead of own implementation) * do not install the uffd as service_fd * use named constants for MAP_ANONYMOUS * do not restore memory pages and then later mark them as uffd handled * remove function find_pages() to search in pages-<id>.img; now using criu functions to find the necessary pages; for each new page search the pages-<id>.img file is opened * only check the UFFDIO_API once * trying to protect uffd code by CONFIG_UFFD; use make UFFD=1 to compile criu with this patch v3: * renamed the server mode from 'uffd' -> 'lazy-pages' * switched client and server roles transferring the UFFD FD * the criu part running in lazy-pages server mode is now waiting for connections * the criu restore process connects to the lazy-pages server to pass the UFFD FD * before UFFD copying anything else the VDSO pages are copied as it fails to copy unused VDSO pages once the process is running. this was necessary to be able to copy all pages. * if there are no more UFFD messages for 5 seconds the lazy-pages server switches in copy mode to copy all remaining pages, which have not been requested yet, into the restored process * check the UFFDIO_API at the correct place * close UFFD FD in the restorer to remove open UFFD FD in the restored process v4: * removed unnecessary madvise() calls ; it seemed necessary when first running tests with uffd; it actually is not necessary * auto-detect if build-system provides linux/userfaultfd.h header. * simplify unix domain socket setup and communication. * use --address to specify the location of the used unix domain socket. v5: * split the userfaultfd patch in multiple smaller patches * introduced vma_can_be_lazy() function to check if a page can be handled by uffd * moved uffd related code from cr-restore.c to uffd.c * handle failure to register a memory page of the restored process with userfaultfd v6: * get PID of to be restored process from the 'criu restore' process; first the PID is transferred and then the UFFD Signed-off-by: -
Adrian Reber authored
This is a first try to include userfaultfd with criu. Right now it still requires a "normal" checkpoint. After checkpointing the application it can be restored with the help of userfaultfd. All restored pages with MAP_ANONYMOUS and MAP_PRIVATE set are marked as being handled by userfaultfd. As soon as the process is restored it blocks on the first memory access and waits for pages being transferred by userfaultfd. To handle the required pages a new criu command has been added. For a userfaultfd supported restore the first step is to start the 'lazy-pages' server: criu lazy-pages -v4 -D /tmp/3/ --address /tmp/userfault.socket This is part 1 of the userfaultfd integration which provides the 'lazy-pages' server implementation. v2: * provide option '--lazy-pages' to enable uffd style restore * use send_fd()/recv_fd() provided by criu (instead of own implementation) * do not install the uffd as service_fd * use named constants for MAP_ANONYMOUS * do not restore memory pages and then later mark them as uffd handled * remove function find_pages() to search in pages-<id>.img; now using criu functions to find the necessary pages; for each new page search the pages-<id>.img file is opened * only check the UFFDIO_API once * trying to protect uffd code by CONFIG_UFFD; use make UFFD=1 to compile criu with this patch v3: * renamed the server mode from 'uffd' -> 'lazy-pages' * switched client and server roles transferring the UFFD FD * the criu part running in lazy-pages server mode is now waiting for connections * the criu restore process connects to the lazy-pages server to pass the UFFD FD * before UFFD copying anything else the VDSO pages are copied as it fails to copy unused VDSO pages once the process is running. this was necessary to be able to copy all pages. * if there are no more UFFD messages for 5 seconds the lazy-pages server switches in copy mode to copy all remaining pages, which have not been requested yet, into the restored process * check the UFFDIO_API at the correct place * close UFFD FD in the restorer to remove open UFFD FD in the restored process v4: * removed unnecessary madvise() calls ; it seemed necessary when first running tests with uffd; it actually is not necessary * auto-detect if build-system provides linux/userfaultfd.h header * simplify unix domain socket setup and communication. * use --address to specify the location of the used unix domain socket v5: * split the userfaultfd patch in multiple smaller patches * introduced vma_can_be_lazy() function to check if a page can be handled by uffd * moved uffd related code from cr-restore.c to uffd.c * handle failure to register a memory page of the restored process with userfaultfd v6: * get PID of to be restored process from the 'criu restore' process; first the PID is transferred and then the UFFD * code has been re-ordered to be better prepared for lazy-restore from remote host * compile test for UFFD availability only once Signed-off-by: -
Adrian Reber authored
For the upcoming userfaultfd integration the lazy-pages mode needs to setup the criu infrastructure to read the pages files. Signed-off-by:
-
