- 30 Oct, 2018 40 commits
-
-
Cyrill Gorcunov authored
Signed-off-by:
Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Radostin Stoyanov authored
Signed-off-by:
Radostin Stoyanov <rstoyanov1@gmail.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Mike Rapoport authored
Fixes cov 191305 Signed-off-by:
Mike Rapoport <rppt@linux.vnet.ibm.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Andrei Vagin authored
It fails too often and nobody knows how to fix it. Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Andrei Vagin authored
>>> CID 164715: (BUFFER_SIZE_WARNING) >>> Calling strncpy with a maximum size argument of 16 bytes on destination array "thread_args[i].comm" of size 16 bytes might leave the destination string unterminated. 3473 strncpy(thread_args[i].comm, core->tc->comm, TASK_COMM_LEN); Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com> Acked-by:
Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Radostin Stoyanov authored
When zdtm.py is executed with `list` sub-command the 'criu_bin' option is not defined and criu.available() fails. $ python test/zdtm.py list Traceback (most recent call last): File "test/zdtm.py", line 2243, in <module> criu.available() File "test/zdtm.py", line 1185, in available if not os.access(opts['criu_bin'], os.X_OK): KeyError: u'criu_bin' However, we don't need to check the existence of criu_bin unless we use the `run` action. Signed-off-by:
Radostin Stoyanov <rstoyanov1@gmail.com> Acked-by:
Adrian Reber <areber@redhat.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Radostin Stoyanov authored
Signed-off-by:
Radostin Stoyanov <rstoyanov1@gmail.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Cyrill Gorcunov authored
It is especially important when accessing a hash -- there must be no negative indices ever. https://jira.sw.ru/browse/PSBM-82945Signed-off-by:
Cyrill Gorcunov <gorcunov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Radostin Stoyanov authored
Most of the typos were found by codespell. Signed-off-by:
Radostin Stoyanov <rstoyanov1@gmail.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Radostin Stoyanov authored
There are no functional changes. Signed-off-by:
Radostin Stoyanov <rstoyanov1@gmail.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Adrian Reber authored
Signed-off-by:
Adrian Reber <areber@redhat.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Alice Frosi authored
Signed-off-by:
Alice Frosi <alice@linux.vnet.ibm.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Andrei Vagin authored
Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Pavel Tikhomirov authored
In commit 23b76949 ("dump: optimize dead_pid_conflict by searching in rbtree") we'd replaced for_each_pstree_item and thread walk search with pstree_pid_by_virt (rb-tree search). The latter already found us the thread with conflicting pid if it exists, the only thing left is to skip if the thread is also a main thread of the thread group (as it was before patch). But some leftover left which checks something wrong: we index ->threads array with "i", but "i" is not a number of the thread it is a number of current dead pid. Not sure if it helps with the initial bug and duplicates, but it might: https://jira.sw.ru/browse/PSBM-55217Signed-off-by:
Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Pawel Stradomski authored
This can happen when running in user namespace with auto-dedup enabled. Right now this means auto-dedup gets disabled. Signed-off-by:
Pawel Stradomski <pstradomski@google.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Pavel Tikhomirov authored
call variables of type RemapFilePathEntry - "rpe" everywhere, similar as we already name them in oher places while on it remove unused second argument of open_remap_linked Signed-off-by:
Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Andrei Vagin authored
./test//zdtm.py --set inhfd run --all --rpc Cc: Adrian Reber <areber@redhat.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Pavel Tikhomirov authored
After running criu test, docker on the node becomes unusable, as it is confused by our leftover cgroups. Surely docker should be fixed to ignore custom cgroups (https://github.com/moby/moby/issues/37601), but we should not leave them after test also. v2: rmdir the holder only if it exists, remove racy wait and remove wrongly added cleanup method in class criu v3: bring back missed semicolon Signed-off-by:
Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Cyrill Gorcunov authored
When checkpointing applications with really big memory slab (like in our vz7 test with 920G of memory) the int type get cutted, we should use long int instead, just like we do in other code pieces. Otherwise get | pie: 756: Daemon waits for command | (01.193097) Wait for ack 12 on daemon socket | (01.193112) Fetched ack: 12 12 0 | (01.193164) 988065 fdinfo 0: pos: 0 flags: 100002/0 | (01.193201) fdinfo: type: 0xb flags: 0100002/0 pos: 0 fd: 0 | (01.193279) 988065 fdinfo 1: pos: 0 flags: 100002/0 | (01.193307) fdinfo: type: 0xb flags: 0100002/0 pos: 0 fd: 1 | (01.193341) 988065 fdinfo 2: pos: 0 flags: 100002/0 | (01.193365) fdinfo: type: 0xb flags: 0100002/0 pos: 0 fd: 2 | (01.193375) ---------------------------------------- | (01.193405) Error (criu/parasite-syscall.c:243): BUG at criu/parasite-syscall.c:243 | pie: 756: Error (criu/pie/parasite.c:676): Trimmed message received (1> Signed-off-by:
Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Cyrill Gorcunov authored
In case if pipe buffers are full the splicing may wakeup reader first with incomplete data transfer. Thus splice data in cycle. Signed-off-by:
Cyrill Gorcunov <gorcunov@gmail.com> Acked-by:
Mike Rapoport <rppt@linux.vnet.ibm.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Pavel Tikhomirov authored
05:57:35.640: 1238: FAIL: fork.c:80: Task 16275 didn't exit (errno = 10 (No child processes)) There is no info about the killing signal in logs, add it. https://jira.sw.ru/browse/PSBM-87579Signed-off-by:
Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Cyrill Gorcunov authored
Integer is too small for big memory slabs. Signed-off-by:
Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Pavel Tikhomirov authored
Signed-off-by:
Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
-
Mike Rapoport authored
Signed-off-by:
Mike Rapoport <rppt@linux.vnet.ibm.com>
-
Mike Rapoport authored
Signed-off-by:
Mike Rapoport <rppt@linux.vnet.ibm.com>
-
Mike Rapoport authored
The stack pointers will be later use by the memory dump to ensure that current stack pages are not treated as lazy. Signed-off-by:
Mike Rapoport <rppt@linux.vnet.ibm.com>
-
Mike Rapoport authored
Currently parasite_thread_ctl for non-leader threads is initialized after we stop the compel daemon. Moving this initialization earlier will allow us to make stack pointers of all threads available during memory dump. Signed-off-by:
Mike Rapoport <rppt@linux.vnet.ibm.com>
-
Mike Rapoport authored
Signed-off-by:
Mike Rapoport <rppt@linux.vnet.ibm.com>
-
Mike Rapoport authored
We need to know what are stack pointers of every thread to ensure that the current stack page will not be treated as lazy. Signed-off-by:
Mike Rapoport <rppt@linux.vnet.ibm.com> Acked-by:
Alice Frosi <alice@linux.vnet.ibm.com> Reviewed-by:
Laurent Dufour <ldufour@linux.vnet.ibm.com>
-
Adrian Reber authored
Signed-off-by:
Adrian Reber <areber@redhat.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Adrian Reber authored
This is obviously not a real check. This only exists, so that CRIU clients/users can check if this CRIU version supports the external network namespace feature. Theoretically the CRIU client or user could also parse the version, but especially for CLI users version comparison in the shell is not easy. This feature check does not exist for RPC as RPC has a special version call which does not require string parsing and the external network namespace feature is available for all CRIU versions newer than 3.9. Signed-off-by:
Adrian Reber <areber@redhat.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Radoslaw Burny authored
Since the processes and fds are restored from images in the increasing order, and they are stored in sorted lists, CRIU always needed (at least in my experiments) to traverse the whole list before inserting them. With this change, lists are traversed in reverse, so the fds should be inserted immediately. Acked-by:
Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by:
Radoslaw Burny <rburny@google.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Adrian Reber authored
The latest patches to cr-service.c broke compilation with gcc-8: criu/cr-service.c: In function ‘setup_opts_from_req’: criu/cr-service.c:323:3: error: ‘strncpy’ specified bound 4096 equals destination size [-Werror=stringop-truncation] strncpy(images_dir_path, opts.imgs_dir, PATH_MAX); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ criu/cr-service.c:343:3: error: ‘strncpy’ specified bound 4096 equals destination size [-Werror=stringop-truncation] strncpy(work_dir_path, opts.work_dir, PATH_MAX); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cc1: all warnings being treated as errors This fixes the errors by specifying the strncpy() size as 'PATH_MAX - 1'. Signed-off-by:
Adrian Reber <areber@redhat.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Adrian Reber authored
With this commit it is possible to specify a configuration file via RPC. In python this would look like this: req.opts.config_file = 'path/to/config_file' With this commit CRIU's configuration file handling works like this: * apply_config(global_conf) * apply_config(user_conf) * apply_config(environment variable) * apply_config(config file via CLI) * apply_rpc_options() or apply_cli_options() * apply_config(rpc_conf) (only for RPC) This is at least (probably) the third iteration of the RPC configuration file code and it still is complicated. Most CRIU options are correctly used by just writing the new values to the corresponding fields of the opts structure. For the RPC case there are, however, a few options (output, work_dir, imgs_dir) which need special handling. So the RPC configuration file is parsed twice. First time to get output, work_dir and imgs_dir. Once those are read and correctly used, the RPC code overwrites all options again by values set by the RPC interface. At the end the RPC configuration file is read a second time and finally overwrites the values set via RPC. Signed-off-by:
Adrian Reber <areber@redhat.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Adrian Reber authored
This test checks the following things: * Does configuration file parsing work at all. * Does the parser detect wrong options. * Does the configuration file work via RPC. * Do the configuration file options not overwrite the RPC settings in the default setup. * Is it possible to tell CRIU to prefer the configuration file via RPC. Signed-off-by:
Adrian Reber <areber@redhat.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Adrian Reber authored
When CRIU is started in RPC mode ('criu swrk') it used to ignore all command-line options and configuration files. This moves the jump to RPC mode after the configuration file parsing to enable configuration. With this configuration files are now also evaluated in RPC mode and it is possible to change the behavior of CRIU via the configuration file if used via RPC. Signed-off-by:
Adrian Reber <areber@redhat.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Adrian Reber authored
With this it is possible to point the environment variable CRIU_CONFIG_FILE to a CRIU configuration file. The order the configuration files are evaluated now is: 1. global (/etc/criu/default.conf) 2. user ($HOME/.criu/default.conf) 3. CRIU_CONFIG_FILE 4. --config FILENAME 5. CLI Signed-off-by:
Adrian Reber <areber@redhat.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Adrian Reber authored
With the previous change to dynamically allocate memory for each possible configuration source (three different configuration files, CLI, RPC) the char * options can no longer directly point to the character strings extracted by getopt() as the memory might be free'd at some point. This introduces a macro to set the char * options which first does a xfree() and then a xstrdup(). Signed-off-by:
Adrian Reber <areber@redhat.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Adrian Reber authored
The code to read and parse configuration files was writing the result of the global configuration file to one variable and the result from the configuration file in the user's home to another variable: char **global_conf = NULL; char **user_conf = NULL; With this change the code now uses dynamic memory allocation to handle the different configuration files. It used to be: * parse global config * parse user config * evaluate global config * evaluate user config * evaluate CLI And now it is: * parse global config * evaluate global config * parse user config * evaluate user config * evaluate CLI This change is in preparation for the upcoming setting of a configuration file via environment variable and RPC configuration file usage. Signed-off-by:
Adrian Reber <areber@redhat.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Adrian Reber authored
This just moves the functions init_opts() and deprecated_ok() also to config.c as that is where most of the option and configuration setup and handling is done today. Signed-off-by:
Adrian Reber <areber@redhat.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-