mir/criu
2
0
Fork 0
mirror of https://github.com/checkpoint-restore/criu synced 2025-08-22 01:51:51 +00:00
Code Issues Releases Wiki Activity
criu/include/file-ids.h

22 lines
466 B
C
Raw Normal View History

files: Use sys_kcmp to find file descriptor duplicates v4 We switch generic-object-id concept with sys_kcmp approach, which implies changes of image format a bit (and since it's early time for project overall, we're allowed to). In short -- previously every file descriptor had an ID generated by a kernel and exported via procfs. If the appropriate file descriptors were the same objects in kernel memory -- the IDs did match up to bit. It allows us to figure out which files were actually the identical ones and should be restored in a special way. Once sys_kcmp system call was merged into the kernel, we've got a new opprotunity -- to use this syscall instead. The syscall basically compares kernel objects and returns ordered results suitable for objects sorting in a userspace. For us it means -- we treat every file descriptor as a combination of 'genid' and 'subid'. While 'genid' serves for fast comparison between fds, the 'subid' is kind of a second key, which guarantees uniqueness of genid+subid tuple over all file descritors found in a process (or group of processes). To be able to find and dump file descriptors in a single pass we collect every fd into a global rbtree, where (!) each node might become a root for a subtree as well. The main tree carries only non-equal genid. If we find genid which is already in tree, we need to make sure that it's either indeed a duplicate or not. For this we use sys_kcmp syscall and if we find that file descriptors are different -- we simply put new fd into a subtree. Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> Acked-by: Pavel Emelyanov <xemul@parallels.com>
2012-02-28 18:27:28 +04:00
#ifndef FILE_IDS_H__
#define FILE_IDS_H__
#include "compiler.h"
#include "types.h"
#include "rbtree.h"
protobuf: Start switching our image entries to Google's protobuf A short story -- there were a long conversation on which format should be used to keep checkpointed data on disk image. We ended up in using Google's Protocol Buffers (see https://developers.google.com/protocol-buffers/ for detailed description). Thus image entries should be convered to PB. This patch converts fdinfo_entry to PB "message fdinfo_entry". Build note: one should have protobuf and protobuf-c installed to be able to build crtools. - http://code.google.com/p/protobuf/ - http://code.google.com/p/protobuf-c/ Inspired-by: Pavel Emelianov <xemul@parallels.com> Inspired-by: Kinsbursky Stanislav <skinsbursky@openvz.org> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
2012-07-12 13:06:00 +04:00
#include "../protobuf/fdinfo.pb-c.h"
file-ids: Enlighten ID generation and storage The unique id is 32 bit and consists only of the subid value. This is _really_ enough. The genid part is just a hint for the tree-search algirythm to avoid unneeded sys_kcmp calls. Plus, generate IDs for special files. This will make it easier to move the regfiles into into separate files (see the respective patch for details). Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
2012-03-24 22:02:10 +04:00
#define FD_PID_INVALID (-2U)
dump: Don't dump file params with on-stack values Otherwise I see output like | Dumping path for 1536412160 fd via self 27 [/usr/bin/screen] where fd is taken from stack and what is worse -- we work with root privilegues, thus dumping _anything_ from stack is very bad idea. With explicitly cleared stack data and FD_DESC_INVALID the log file will have an entry like | Dumping path for -3 fd via self 27 [/usr/bin/screen] Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
2012-05-28 15:56:00 +04:00
#define FD_DESC_INVALID (-3U)
files: Use sys_kcmp to find file descriptor duplicates v4 We switch generic-object-id concept with sys_kcmp approach, which implies changes of image format a bit (and since it's early time for project overall, we're allowed to). In short -- previously every file descriptor had an ID generated by a kernel and exported via procfs. If the appropriate file descriptors were the same objects in kernel memory -- the IDs did match up to bit. It allows us to figure out which files were actually the identical ones and should be restored in a special way. Once sys_kcmp system call was merged into the kernel, we've got a new opprotunity -- to use this syscall instead. The syscall basically compares kernel objects and returns ordered results suitable for objects sorting in a userspace. For us it means -- we treat every file descriptor as a combination of 'genid' and 'subid'. While 'genid' serves for fast comparison between fds, the 'subid' is kind of a second key, which guarantees uniqueness of genid+subid tuple over all file descritors found in a process (or group of processes). To be able to find and dump file descriptors in a single pass we collect every fd into a global rbtree, where (!) each node might become a root for a subtree as well. The main tree carries only non-equal genid. If we find genid which is already in tree, we need to make sure that it's either indeed a duplicate or not. For this we use sys_kcmp syscall and if we find that file descriptors are different -- we simply put new fd into a subtree. Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> Acked-by: Pavel Emelyanov <xemul@parallels.com>
2012-02-28 18:27:28 +04:00
#define MAKE_FD_GENID(dev, ino, pos) \
(((u32)(dev) ^ (u32)(ino) ^ (u32)(pos)))
file-ids: Enlighten ID generation and storage The unique id is 32 bit and consists only of the subid value. This is _really_ enough. The genid part is just a hint for the tree-search algirythm to avoid unneeded sys_kcmp calls. Plus, generate IDs for special files. This will make it easier to move the regfiles into into separate files (see the respective patch for details). Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
2012-03-24 22:02:10 +04:00
struct fdinfo_entry;
protobuf: Start switching our image entries to Google's protobuf A short story -- there were a long conversation on which format should be used to keep checkpointed data on disk image. We ended up in using Google's Protocol Buffers (see https://developers.google.com/protocol-buffers/ for detailed description). Thus image entries should be convered to PB. This patch converts fdinfo_entry to PB "message fdinfo_entry". Build note: one should have protobuf and protobuf-c installed to be able to build crtools. - http://code.google.com/p/protobuf/ - http://code.google.com/p/protobuf-c/ Inspired-by: Pavel Emelianov <xemul@parallels.com> Inspired-by: Kinsbursky Stanislav <skinsbursky@openvz.org> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
2012-07-12 13:06:00 +04:00
extern int fd_id_generate(pid_t pid, FdinfoEntry *fe);
vma: Remove FDINFO_MAP fd type The regfile's ID of a VMA is stored in its shmid field. And the file itself if sumped into regfiles.img image with 'special'-ly generated ID (i.e. -- just allocate a new unique one). Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
2012-04-09 12:57:38 +04:00
extern u32 fd_id_generate_special(void);
file-ids: Show collected subtree at the end of dump Just for debugging. Useful to know how the tree was built Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
2012-03-24 16:52:09 +04:00
extern void fd_id_show_tree(void);
files: Use sys_kcmp to find file descriptor duplicates v4 We switch generic-object-id concept with sys_kcmp approach, which implies changes of image format a bit (and since it's early time for project overall, we're allowed to). In short -- previously every file descriptor had an ID generated by a kernel and exported via procfs. If the appropriate file descriptors were the same objects in kernel memory -- the IDs did match up to bit. It allows us to figure out which files were actually the identical ones and should be restored in a special way. Once sys_kcmp system call was merged into the kernel, we've got a new opprotunity -- to use this syscall instead. The syscall basically compares kernel objects and returns ordered results suitable for objects sorting in a userspace. For us it means -- we treat every file descriptor as a combination of 'genid' and 'subid'. While 'genid' serves for fast comparison between fds, the 'subid' is kind of a second key, which guarantees uniqueness of genid+subid tuple over all file descritors found in a process (or group of processes). To be able to find and dump file descriptors in a single pass we collect every fd into a global rbtree, where (!) each node might become a root for a subtree as well. The main tree carries only non-equal genid. If we find genid which is already in tree, we need to make sure that it's either indeed a duplicate or not. For this we use sys_kcmp syscall and if we find that file descriptors are different -- we simply put new fd into a subtree. Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org> Acked-by: Pavel Emelyanov <xemul@parallels.com>
2012-02-28 18:27:28 +04:00
#endif /* FILE_IDS_H__ */
Reference in New Issue Copy Permalink