- 18 Oct, 2013 1 commit
-
-
Pavel Emelyanov authored
As planned, this was bugfix-mainly release. However, some new features were added. Looking forward the v1.0 release :) Signed-off-by:Pavel Emelyanov <xemul@parallels.com>
-
- 17 Oct, 2013 2 commits
-
-
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
There can be a more sophisticated security policy, but right now generic non-root user doesn't have any bits in there, so requiring them to be zero is a sane starting point. Signed-off-by:
-
- 15 Oct, 2013 12 commits
-
-
Pavel Emelyanov authored
There's ... a number of places where we want to do something with /proc/self/fd/%d path. Each time we guess buffer size that is enough for this. Make standard constant for this and save some space on stack and drop args for some functions. Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
CRIU puts wd-s for one inotify in one row (one after another), so when collecting next wd, we can find the ify to attach them to faster. Signed-off-by: -
Pavel Emelyanov authored
The inotify_add_watch generates wd-s one-by one. We cannot request for one, thus we call this syscall till the required wd is generated. Thus, if we want to restore several wd-s for an inotify, we have to put them in ascending order. Otherwise we may restore watch with higher wd earlier and will thus not be able to generate the lower wd in a reasonable time. Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
This can be broken image, need to handle this error gracefully. Signed-off-by: -
Pavel Emelyanov authored
Handle the simplest (remap) case early. This makes code simpler and reduces one level of indent. Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by:
-
- 14 Oct, 2013 3 commits
-
-
Cyrill Gorcunov authored
Convenient for debug. | (00.005999) 3857: fsnotify: Restore inotify watch for 0x00800002:0x0000000000000002 (via /proc/self/fd/5 -> /) | (00.005999) 3857: fsnotify: Restore inotify watch for 0x00800002:0x0000000000083a93 (via /home/criu/test/zdtm/live/static/inotify-removed (deleted).cr.1.ghost) Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
-
Ruslan Kuprieiev authored
Hi! Added "has_log_level = true" to test.c, so "log_level = 4" would have effect. Also added log_level to test.py, for symmetry with test.c. Signed-off-by:
Ruslan Kuprieiev <kupruser@gmail.com> Signed-off-by:
-
Cyrill Gorcunov authored
Otherwise | Error (proc_parse.c:227): Can't parse: 555555554000-555555577000 r-xp 00000000 b6:d2f61 133545 /sbin/init Signed-off-by:
-
- 11 Oct, 2013 7 commits
-
-
Pavel Emelyanov authored
Signed-off-by: -
Cyrill Gorcunov authored
Igor reported the following file lock | (00.003139) lockinfo: 4:POSIX ADVISORY WRITE 46567 b6:5f0b1:524702 0 EOF | (00.003154) lockinfo: 5:POSIX ADVISORY WRITE 46559 b6:5f0b1:524661 0 EOF | (00.003172) lockinfo: 6:POSIX ADVISORY WRITE 46543 b6:5f0b1:524326 0 0 | (00.003188) lockinfo: 7:POSIX ADVISORY WRITE 46543 b6:5f0b1:524367 0 EOF where device maj number is pretty big and parsing failed. Fix it removing field width. Reported-by:
Igor Sukhih <igor@parallels.com> Signed-off-by:
-
Pavel Emelyanov authored
Logs are put into dedicated logfd, cwd is not used as well. Signed-off-by: -
Pavel Emelyanov authored
This is where such stuff is typically placed. Signed-off-by: -
Cyrill Gorcunov authored
In case if we hit error returned from syscall, better to print error code for easier understanding of the protblem. Signed-off-by:
-
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
This can hppen if criu is run in container. Reported-by:
Frederico Araujo <araujof@gmail.com> Signed-off-by:
-
- 10 Oct, 2013 14 commits
-
-
Cyrill Gorcunov authored
To get more detailed error desciption. Also print watchdog number if it exceed expected, for better error output. Signed-off-by:
-
Cyrill Gorcunov authored
It's a way more easier to read. Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Jamie Liu authored
Signed-off-by:
Jamie Liu <jamieliu@google.com> Signed-off-by:
-
Pavel Emelyanov authored
Signed-off-by: -
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
Signed-off-by:
-
Cyrill Gorcunov authored
This kind of netdevice will serve for external links such as venet, macvlan/vlan and etc. Signed-off-by:
-
Pavel Emelyanov authored
Don't carry it around in a static global variable. Would be useful for pidns leaks (processes entered one) scan. Signed-off-by: -
Pavel Emelyanov authored
-
Pavel Emelyanov authored
Signed-off-by: -
Pavel Emelyanov authored
We only get there after and because-of family checks. No need to check them again. Signed-off-by: -
Pavel Emelyanov authored
Signed-off-by: -
Cyrill Gorcunov authored
There is no much point to strdup this value obtained from command line. It sits in environment and we don't modify it at all. Signed-off-by:
-
- 04 Oct, 2013 1 commit
-
-
Cyrill Gorcunov authored
The maximal size which may be used in the kernel for sending TCP data on restore is varies depending on how many memory installed on the system, moreover the memory allocated for "read queue" is bigger than used for "write queue". Thus when we checkpointed a big slab of data we need to figure out which size is allowed for sending data on restore. For this we read /proc/sys/net/ipv4/tcp_[wmem|rmem] on restore and calculate the size needed, then we simply chop data to segements and send it in a loop. Typical output on restore is something like | (00.013001) 30110: TCP queue memory limits are 2097152:3145728 https://bugzilla.openvz.org/show_bug.cgi?id=2751 [xemul: moved stuff to kerndat.c] Reported-by:
Andrey Vagin <avagin@openvz.org> Signed-off-by:
-
