- 31 Jan, 2012 11 commits
-
-
Kir Kolyshkin authored
files.c: In function ‘collect_fd’: files.c:111:2: error: format ‘%d’ expects type ‘int’, but argument 3 has type ‘u64’ files.c: In function ‘open_fd’: files.c:348:3: error: format ‘%d’ expects type ‘int’, but argument 2 has type ‘u64’ files.c: In function ‘receive_fd’: files.c:425:5: error: format ‘%d’ expects type ‘int’, but argument 4 has type ‘u64’ files.c:425:5: error: format ‘%d’ expects type ‘int’, but argument 5 has type ‘u64’ Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org>
-
Kir Kolyshkin authored
sockets.c: In function ‘try_dump_socket’: sockets.c:366:3: error: format ‘%d’ expects type ‘int’, but argument 4 has type ‘__ino_t’ Signed-off-by:
-
Kir Kolyshkin authored
cr-show.c: In function ‘show_pipes’: cr-show.c:119:3: error: format ‘%8lx’ expects type ‘long unsigned int’, but argument 2 has type ‘u32’ cr-show.c:119:3: error: format ‘%8lx’ expects type ‘long unsigned int’, but argument 3 has type ‘u32’ cr-show.c:119:3: error: format ‘%8lx’ expects type ‘long unsigned int’, but argument 4 has type ‘u32’ cr-show.c:119:3: error: format ‘%8lx’ expects type ‘long unsigned int’, but argument 5 has type ‘u32’ Signed-off-by:
-
Kir Kolyshkin authored
cr-dump.c: In function ‘dump_one_reg_file’: cr-dump.c:128:2: error: format ‘%8x’ expects type ‘unsigned int’, but argument 5 has type ‘long unsigned int’ cr-dump.c: In function ‘dump_one_pipe’: cr-dump.c:223:2: error: format ‘%d’ expects type ‘int’, but argument 2 has type ‘long unsigned int’ cr-dump.c:237:3: error: format ‘%8lx’ expects type ‘long unsigned int’, but argument 2 has type ‘u32’ cr-dump.c:237:3: error: format ‘%8lx’ expects type ‘long unsigned int’, but argument 3 has type ‘u32’ cr-dump.c:237:3: error: format ‘%8lx’ expects type ‘long unsigned int’, but argument 4 has type ‘u32’ cr-dump.c:237:3: error: format ‘%8lx’ expects type ‘long unsigned int’, but argument 5 has type ‘u32’ cr-dump.c:240:3: error: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long unsigned int’ cr-dump.c: In function ‘dump_one_fd’: cr-dump.c:257:3: error: format ‘%d’ expects type ‘int’, but argument 5 has type ‘long unsigned int’ cr-dump.c:262:3: error: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long unsigned int’ cr-dump.c:272:4: error: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long unsigned int’ cr-dump.c:286:4: error: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long unsigned int’ cr-dump.c:295:2: error: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long unsigned int’ cr-dump.c: In function ‘dump_task_files’: cr-dump.c:340:3: error: too few arguments for format Signed-off-by:
-
Kir Kolyshkin authored
proc_parse.c: In function ‘parse_maps’: proc_parse.c:75:6: error: format ‘%Lu’ expects type ‘long long unsigned int’, but argument 5 has type ‘u64’ proc_parse.c:118:5: error: format ‘%Lu’ expects type ‘long long unsigned int’, but argument 5 has type ‘u64’ Signed-off-by:
-
Kir Kolyshkin authored
cr-restore.c: In function ‘fixup_vma_fds’: cr-restore.c:578:4: error: format ‘%d’ expects type ‘int’, but argument 6 has type ‘long unsigned int’ cr-restore.c: In function ‘sigreturn_restore’: cr-restore.c:1693:4: error: format ‘%li’ expects type ‘long int’, but argument 4 has type ‘int’ cr-restore.c:1738:3: error: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long int’ cr-restore.c:1751:3: error: format ‘%d’ expects type ‘int’, but argument 4 has type ‘long int’ cr-restore.c:1755:3: error: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long int’ cr-restore.c:1868:4: error: format ‘%8p’ expects type ‘void *’, but argument 3 has type ‘long int’ Signed-off-by:
-
Kir Kolyshkin authored
This way gcc will be able to catch invalid format bugs. Signed-off-by:
-
Kir Kolyshkin authored
When trying to compile the beast with clang, it complains: ==== ./include/lock.h:33:2: error: indirection of non-volatile null pointer will be deleted, not trap BUG_ON(ret < 0); ^~~~~~~~~~~~~~~ In file included from restorer.c:18: ./include/util.h:118:27: note: instantiated from: #define BUG_ON(condition) BUG_ON_HANDLER((condition)) ^ ./include/util.h:100:4: note: instantiated from: *(unsigned long *)NULL = 0xdead0000 + __LINE__; \ ^ ==== Make clang happy again by adding 'volatile'. Signed-off-by: -
Kir Kolyshkin authored
This is a standard convention to print error message (i.e. strerror(errno)) at the end of line, like this: Cannot remove file: Permission denied So pr_perror is fixed to follow this convention (using GNU extension %m helps a lot here). Unfortunately, due to this we have to make pr_perror() print a new line character, too, so we had to strip it from the all pr_perror() invocations. That (appending a newline) also makes pr_perror() a black sheep in the herd of pr_* helpers, but what can we do? Worst case scenario is an extra newline after an error message, not too harmful. An alternative approach (stripping the newline from the passed format string and re-adding it) was discussed thoroughly, and it was decided that such a hack looks a bit too dirty. Signed-off-by:Pavel Emelyanov <xemul@parallels.com> Signed-off-by:
-
Stanislav Kinsbursky authored
Generic code will be used for other namespaces. Signed-off-by:
Stanislav Kinsbursky <skinsbursky@parallels.com> Acked-by:
-
Kir Kolyshkin authored
Found using clang: cr-restore.c:796:8: error: use of unary operator that may be intended as compound assignment (+=) size =+ ret; ^~ Signed-off-by:
-
- 30 Jan, 2012 17 commits
-
-
Konstantin Khlebnikov authored
fix compilation error: cr-restore.c:621:13: error: variably modified ‘zpage’ at file scope Signed-off-by:
Konstantin Khlebnikov <khlebnikov@openvz.org> Signed-off-by:
-
Kir Kolyshkin authored
Function pr_perror() already spits out strerror(errno), no need to do it in the calling code. Signed-off-by:
-
Kir Kolyshkin authored
Cleaning a few space-at-EOL occurences, plus one spaces-instead-of-tab. Found using: git grep -n '[[:space:]]$' git grep -n ' ' Signed-off-by:
-
Cyrill Gorcunov authored
It's suitable not for info only but in debug purpose as well. Signed-off-by:
Pavel Emelyanov <xemul@openvz.org>
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Andrey Vagin authored
Signed-off-by:
Andrey Vagin <avagin@openvz.org> Acked-by:
-
Andrey Vagin authored
Signed-off-by:
-
Cyrill Gorcunov authored
* pre: zdtm: Tests for xids and caps Conflicts: test/zdtm.sh The sockets00 test was added earlier. Signed-off-by: -
Pavel Emelyanov authored
Rather simple and straightforward and atomic tests should be. The only problem is that after changing any from the subj the subsequent opens for .out/.pid files fail so test actually forks in the beginning. That said -- we need some API in the lib/ for such forkers. Signed-off-by:
-
Pavel Emelyanov authored
Dumping is simple. All but secbits can be read from proc, secbits are got from parasite. Restoring is a bit tricky -- when you change anything on kernel cred's struct it performs sophisticated checks and can change some more stuff than requested, so the creds restoration procedure is carefully commented step-by-step. Another thing to mention is that creds are restored after everything else, i.e. right before performing final threads sync and sigreturns. This is done to avoid potential problems with insufficient caps for restoring other stuff (e.g. CAP_DAC_OVERRIDE or zero euid is most likely required for opening any image file and the notorious control /proc/sys/kernel/ns_last_pid, which in turn is performed till the very last moment). Signed-off-by:
-
Pavel Emelyanov authored
These are setXXXid, capset and various bits for prctl and caps machinery. The thing is that the caps API is not yet fully in glibc so we have to declare some bits even for core code, not just for restorer/parasite. Signed-off-by:
-
Pavel Emelyanov authored
All the IDs and caps are in there. Just read them for future use. Signed-off-by:
-
Pavel Emelyanov authored
Add command and basis for dumping minor bits for task from parasite code. It's supposed to retrieve minor bits form tasks which cannot be read from /proc. Signed-off-by:
-
Cyrill Gorcunov authored
I occasionally droppped this file but it's a part of commit dcd64e9d So add it back. Signed-off-by:
-
Andrey Vagin authored
Signed-off-by: -
Cyrill Gorcunov authored
Just disable it for a while, otherwise we get in test/zdtm/live/streaming/netlink00.c cc1: warnings being treated as errors netlink00.c: In function ‘form_request_del’: netlink00.c:311: error: dereferencing pointer ‘rtap’ does break strict-aliasing rules netlink00.c:312: error: dereferencing pointer ‘rtap’ does break strict-aliasing rules netlink00.c:310: note: initialized from here netlink00.c: In function ‘form_request_add’: netlink00.c:271: error: dereferencing pointer ‘rtap’ does break strict-aliasing rules netlink00.c:272: error: dereferencing pointer ‘rtap’ does break strict-aliasing rules netlink00.c:270: note: initialized from here Signed-off-by:
-
- 29 Jan, 2012 1 commit
-
-
Cyrill Gorcunov authored
It's outdated anyway. Signed-off-by:
-
- 28 Jan, 2012 3 commits
-
-
Cyrill Gorcunov authored
Signed-off-by: -
Cyrill Gorcunov authored
Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by:
-
- 27 Jan, 2012 8 commits
-
-
Cyrill Gorcunov authored
Signed-off-by: -
Cyrill Gorcunov authored
This covers UNIX stream sockets including in-flight connections. No dgram sockets yet implemented. Signed-off-by: -
Cyrill Gorcunov authored
It's done in two steps - On checkpoint we find which icons are present over all sockets and setup peer number to appropriate listening socket - On restore we collect listening sockets and once we find in-flight connection we search for appropriate listening socket name and use it to call connect() then Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
