105
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: + + Line 7:
Line 9: − + − |- − | kernel/crtools || Remap [[Vdso]] || medium || - || When at restore VDSO is found not in the place it was on dump we should <code>mremap()</code> one. Unfortunately not always we can do it, need to fix the kernel. − |- − | crtools || Make dump and restore work under [[selinux]] || medium || - || Selinux imposes more restrictions on the stuff we typically do. Line 18:
Line 16: − |- − | crtools || Make [[RPC]] "swrk" mode public || medium || xemul || There's an "swrk" action in CRIU [[Usage|CLI API]]. This turns CRIU into service worker accepting RPC commands. This mode is not documented. Need to standartify one and make public. Line 30:
Line 26: − |- − | crtools || Deduplication for shmem [[memory dumps]] || easy || - || We have dedup action and --auto-dedup option for dump/restore which only works for pid pagemaps. Need the same for shmem. − |- − | crtools || Show what was left in the system after dump || easy || - || When we use [[Invisible files|--link-remap]] option or [[TCP connection|--tcp-established]] one CRIU leaves some traces in the system, in particular -- temporary hard links in the former case and iptables rules in the latter. Need some way to show these to the user. − |- − | crtools || Decode flags from images into symbolic names || easy || - || When we print images contents with [[CRIT]] the flags fields are shown in decimal/hex numbers. It would be nice to print the symbolic names for known flags in some form. − |- − | crtools || Leases support || easy || - || The F_SETLEASE/F_GETLEASE API is not currently supported, but doesn't differ much from regular locks. − |- − | kernel/crtools || Make proper "check lock present" API in the kernel || medium || - || Currently we detect where a file lock belongs to by locking the file again with the alternative lock type and check how kernel reacts on that. This is not nice as it may tune the lock state on a file. Instead we need the "check lock on fd" call in the kernel. Line 52:
Line 38: − |- − | crtools || AIO with pending events || medium || - || When we dump AIO ring we check it not to contain events inside and abort the dump otherwise. Need to dump events too and put them back on restore. Line 60:
Line 44: − |- − | crtools || Dump tasks from cgroup || easy || - || Currently criu dumps a subtree from given pid. It makes sense to request CRIU to dump a set of tasks from given cgroup. − |- − | crtools || Support OFD posix locks || easy || - || These are still rarely used, but exist. Might make sense to support them in advance, it looks like kernel API allows for that. − |- − | crtools || Optimize kcmp calls || medium || - || CRIU build [[kcmp trees]] to find out IDs of such objects as MM, FDT and others. Currently we kcmp all tasks to get the ID, but we can improve that by pre-generating ID based on objects that live on MM, FS, etc. If pre-ID of two tasks matches, then we call kcmp, if not -- objects ''are'' different. − |- − | crtools || Shmem changes tracking || medium || - || Memory changes tracker works on anonymous private mappings only. Anonymous shmem is not in active use by server applications, so we don't support one currently. Supporting it should be done by tracking the changes from all the tasks that ''could'' write into the segment. For anon shared memory and sysvipc segment inside IPC namespace this works reliably. − |- − | crtools || [[FUSE]] mount points || hard || - || When dumping mountpoints we explicitly check the filesystem mounted. The thing is -- not all filesystems can be just ignored on dump. E.g. FUSE mount involves a user-space daemon that is responsible for the files tree contents. If we just kill one on dump we might not be able to restore it. Need to special-care one. − |- − | crtools || 32-bit tasks || hard || Cyrill || For x86 we only dump and restore 64-bit tasks. Doing 32-bit should also be done, but keep in mind, that not only 64-bit tree OR 32-bit tree should be supported. There can be mixed 64-and-32-bit trees out there and CRIU should support those too. − |- − | crtools || Generate task's core file out of images with [[CRIT]] || medium || Ruslan Kuprieiev || Nothing special -- just take core.img, mm.img and pagemap.img and produce the canonical core image out of those. − |- − | crtools || Modify restored resources run-time in [[CRIT]] daemon || medium || - || Sometimes it might make sense to tune the objects fro images on restore. E.g. -- change the IP address of sockets from task above or fix file paths to be "chroot-ed". The best solution seems to be in launching CRIT in daemon mode, telling it what images and how to modify and teaching CRIU to "filter" the pb objects read from images through this daemon. Line 95:
Line 63: − | kernel?/crtools || TCP conntrack-ed connections || medium || - || When a container uses conntracks inside, we cannot just dump and restore alive TCP connection. Otherwise on restore the resurrected packets will be blocked by connection tracker as they would not be recognized as established connection. Need to check whether connection tracking is ON, dump the needed conntrack info and put the tracker back.+ − |- − | crtools || Bridges in container || medium || - || The bridge device state should be read, saved and restored. − |- − | crtools || VLANs in containers || medium || - || Vlan (802.1q) device state should be read, saved and restored. − |- − | crtools || [[PPP]] support || medium || - || PPP consists of several things, not just ppp devices. If container uses PPP we should take care of it, currently CRIU just aborts. − |- − | crtools/kernel || [[NFS mount points]] support || hard || - || NFS mount points from inside container cannot be easily restored. The thing is -- if we want to restore opened file we will go ahead and [[How hard is it to open a file|call]] the open system call. If the file in question resides on NFS, the latter might need to go to network to check whether the file actually exists and set up the handle. But if the networking is still not restored this operation would fail and we'll have to fail the whole restore. In order to untie this chicken-and-egg problem we may go in two directions. − |- − − |- − | crtools || Validate .img files || easy || - || [[CRIT]] sub-task. For a given set of image files check, that they are in "restorable" shape, i.e. contain valid data and no pieces are missing. − + − + − + − + − + − + − +
vdso remapping fixed for arm64/arm32/ppc64/ia32 running on x86_64, s390 doesn't need this - looks like, each supported architecture is covered; for any new architecture there is an easy way now in kernel to add .mremap() to special_mapping_ops
{{note|This list is being transformed into the [https://github.com/checkpoint-restore/criu/issues github issues]}}
{| class="wikitable sortable"
{| class="wikitable sortable"
|-
|-
! comments
! comments
|-
|-
| crtools || Non-full mntns dump || medium || - || Systemd launches services in a new mount namespace with a single change -- /tmp is re-mounted into a private one(PrivateTmp option). Need to invent an API for dumping only a part of mntns.
| tests || automate process of measurement code coverage || easy || - || It is required to automate process of getting code coverage. We have code coverage results [http://criu.org/cov/ measured in 2012]. Would be nice to get up to date results on periodic basis and without manual actions.
|-
|-
| crtools || Inherit resources, not restore || medium || - || Sigactions are restored for every task before it fork()-s. Then children check for the sa_action from their image matches to one it got from parent. Need to do the same for rlimits, maybe other resources too.
| crtools || Inherit resources, not restore || medium || - || Sigactions are restored for every task before it fork()-s. Then children check for the sa_action from their image matches to one it got from parent. Need to do the same for rlimits, maybe other resources too.
|-
|-
| crtools || New images format || medium (v2) || - || See [[what's bad with V1 images]]
| crtools || New images format || medium (v2) || - || See [[what's bad with V1 images]]
|-
|-
| kernel/crtools || Tune the start-time of tasks || medium || - || When we restore tasks their start-time goes forward (since we create the new task effectively). Need to address this somehow, most likely with the [[time namespace]].
| kernel/crtools || Tune the start-time of tasks || medium || - || When we restore tasks their start-time goes forward (since we create the new task effectively). Need to address this somehow, most likely with the [[time namespace]].
|-
|-
| kernel || Make pipes swappable || hard || - || When [[Memory dumping and restoring|pre-dumping]] memory we pull all the task's memory into pipe with vmsplice and then send it via network splicing the pages into socket. During this period all the memory is effectively pinned as pages in pipe are not swappable.
| kernel || Make pipes swappable || hard || - || When [[Memory dumping and restoring|pre-dumping]] memory we pull all the task's memory into pipe with vmsplice and then send it via network splicing the pages into socket. During this period all the memory is effectively pinned as pages in pipe are not swappable.
|-
|-
| kernel/crtools || Adjust per-task/-container timers offsets || medium || - || Absolute timers differ on different nodes. When live migrating a task/container this difference may (and will) screw the timers up.
| kernel/crtools || Adjust per-task/-container timers offsets || medium || - || Absolute timers differ on different nodes. When live migrating a task/container this difference may (and will) screw the timers up.
|-
|-
| crtools || [[time namespace|Shift timers' timeouts]] according to the actual C-to-R delay || medium || - || If we pause tasks between C and R we, probably, need to adjust timers respectively. "Medium" complexity is because it's unclear ''what'' to do, not ''how''.
| crtools || [[time namespace|Shift timers' timeouts]] according to the actual C-to-R delay || medium || - || If we pause tasks between C and R we, probably, need to adjust timers respectively. "Medium" complexity is because it's unclear ''what'' to do, not ''how''.
|-
|-
| kernel/crtools || Put call to mmap into VDSO || easy || Cyrill || To put the [[parasite code]] into target process we modify its code to call the <code>mmap()</code> system call (and the unmodify it back) and put the parasite into new area. Oleg Nesterov suggests not to patch victim, but to always have one on VDSO.
| kernel/crtools || Put call to mmap into VDSO || easy || Cyrill || To put the [[parasite code]] into target process we modify its code to call the <code>mmap()</code> system call (and the unmodify it back) and put the parasite into new area. Oleg Nesterov suggests not to patch victim, but to always have one on VDSO.
|-
|-
| crtools || Rollback tree state || medium || - || When we checkpointed process tree with -R option (let them run after checkpoint) we might want to return the tasks into checkpointed state on the same machine. Currently this can only be done by killing the processes and restoring them from scratch. If we could ask CRIU to restore the images ''into'' the ready processes that could speed things up, especially if carefully caring about [[memory changes tracking]].
| crtools || Rollback tree state || medium || - || When we checkpointed process tree with -R option (let them run after checkpoint) we might want to return the tasks into checkpointed state on the same machine. Currently this can only be done by killing the processes and restoring them from scratch. If we could ask CRIU to restore the images ''into'' the ready processes that could speed things up, especially if carefully caring about [[memory changes tracking]].
|-
|-
| crtools || Restore arbitrary mountpoints tree || hard || - || Linux kernel can construct tricky knows with [[mount points]]. We don't support arbitrary configuration of such things, only those that are in active use by software. Need to fix them up.
| crtools || Restore arbitrary mountpoints tree || hard || - || Linux kernel can construct tricky knows with [[mount points]]. We don't support arbitrary configuration of such things, only those that are in active use by software. Need to fix them up.
|-
|-
| crtools || [[Lazy migration]] using [[userfaultfd]] || medium || xemul || Lazy migration is when we move all the tasks on another node, but leave theirs memory on the source one. Not to allow tasks read garbage from empty address space we protect all of it as inaccessible. When tasks start reading/writing the mem they got page-fault-ed. With the userfaultfd technology it can be possible to intercept the #PF, pull the page from source node and map it into expected address.
| crtools || [[Lazy migration]] using [[userfaultfd]] || medium || xemul || Lazy migration is when we move all the tasks on another node, but leave theirs memory on the source one. Not to allow tasks read garbage from empty address space we protect all of it as inaccessible. When tasks start reading/writing the mem they got page-fault-ed. With the userfaultfd technology it can be possible to intercept the #PF, pull the page from source node and map it into expected address.
|-
|-
| crtools || Speed up [[logging]] || medium || Cyrill || Synchronous formatting and writes into log files slow things down. On the other hand turning logs off make it impossible to troubleshoot.
| crtools || Speed up [[logging]] || medium || Cyrill || Synchronous formatting and writes into log files slow things down. On the other hand turning logs off make it impossible to troubleshoot.
|-
|-
| crtools || Sanitize [[logging]] messages || hard || - || Currently log messages are printed w/o any logic, it's hard to analize what has happened when CRIU fails. Need to improve that by, e.g. categorizing images and [[When C/R fails|explaining them]] in more details.
| crtools || Sanitize [[logging]] messages || hard || - || Currently log messages are printed w/o any logic, it's hard to analize what has happened when CRIU fails. Need to improve that by, e.g. categorizing images and [[When C/R fails|explaining them]] in more details.
|-
|-
| crtools || Page transfer filters || medium || - || The page-xfer engine just splices the pages from stealing pipes into socket. Packing or encrypting the data would be nice. Maybe it's purely for [[P.Haul]]?
| crtools || Page transfer filters || medium || - || The page-xfer engine just splices the pages from stealing pipes into socket. Packing or encrypting the data would be nice. Maybe it's purely for [[P.Haul]]?
|-
|-
| crtools || TCP socket migration with changed IP || medium || - || It might make sense to migrate a tcp connection on a box with changed IP address _if_ both boxes are NAT-ed to the destination. We will then have to go to NAT box and fix the conntracks in that case and use CRIT images modifucation facilities.
| crtools || TCP socket migration with changed IP || medium || - || It might make sense to migrate a tcp connection on a box with changed IP address _if_ both boxes are NAT-ed to the destination. We will then have to go to NAT box and fix the conntracks in that case and use CRIT images modifucation facilities.
| kernel/crtools || [[TCP repair TODO|TCP repair fixes]] || hard || - || We can dump and restore live [[TCP connection]]. There are some issues with it, that should be fixed.
| kernel/crtools || [[TCP repair TODO|TCP repair fixes]] || hard || - || We can dump and restore live [[TCP connection]]. There are some issues with it, that should be fixed.
|-
|-
| kernel || [[Seamless kernel upgrade]] || hard || xemul || Briefly — dump tasks (into memory), change the kernel w/ kexec, then restore tasks back. From the tasks and remote client perspective tasks has just stopped and then resumed on the newer kernel. Can be a good complement to the classic live-patching technology.
| kernel || [[Seamless kernel upgrade]] || hard || xemul || Briefly -- dump tasks (into memory), change the kernel w/ kexec, then restore tasks back. From the tasks and remote client perspective tasks has just stopped and then resumed on the newer kernel. Can be a good complement to the classic live-patching technology.
|-
|-
| crtools || Restore arbitrary process tree || hard || - || Need to restore any process tree, which could be created with help PR_SET_CHILD_SUBREAPER and CLONE_PARENT. Processes can share other resources [http://man7.org/linux/man-pages/man2/clone2.2.html clone(2)]. Look at [http://git.criu.org/?p=crtools.git;a=blob;f=test/zdtm/live/static/session02.c;hb=HEAD session02]. The task of resolving the given images into operations we might need to perform seem to be NP (not proven though).
| crtools || Restore arbitrary process tree || hard || - || Need to restore any process tree, which could be created with help PR_SET_CHILD_SUBREAPER and CLONE_PARENT. Processes can share other resources [http://man7.org/linux/man-pages/man2/clone2.2.html clone(2)]. Look at [https://github.com/checkpoint-restore/criu/blob/master/test/zdtm/static/session02.c session02]. The task of resolving the given images into operations we might need to perform seem to be NP (not proven though).
|-
|-
| crtools || C/R [[X applications]] || hard || Ruslan Kuprieiev || Dump/restore of graphical applications (see about [[integration]]). In case of X app part of its state is stored into the X-server. Need the way to fetch this state during dump and put this state back into the server on restore. Requires fixing the X-server software too.
| crtools || C/R [[X applications]] || hard || Ruslan Kuprieiev || Dump/restore of graphical applications (see about [[integration]]). In case of X app part of its state is stored into the X-server. Need the way to fetch this state during dump and put this state back into the server on restore. Requires fixing the X-server software too.
|-
|-
| crtools/kernel || Undo semaphores || medium || Cyrill Gorcunov || These are SysVIPC objects created with semctl() and SEM_UNDO flag. Shame on us, we don't even detect these are created. Fortunately they are not in active use. Need to do it -- dump and restore. Requires modifications from both sides -- criu and kernel.
| crtools || More detailed RPC fail codes || easy || - || Currently only 3 typical errors are reported(see [https://github.com/checkpoint-restore/criu/blob/master/criu/include/cr-errno.h#L8 include/cr-errno.h]). Need to extend this set as currently it's hard to understand what has happened w/o analysing CRIU log files.
|-
|-
| crtools || More detailed RPC fail codes || easy || - || Currently only 3 typical errors are reported(see [https://github.com/xemul/criu/blob/master/include/cr-errno.h#L8 include/cr-errno.h]). Need to extend this set as currently it's hard to understand what has happened w/o analysing CRIU log files.
| crtools || Make CRIU work on AArch32 with CONFIG_KUSER_HELPERS=n || medium || cov || CRIU currently fails on AArch32 kernels built with CONFIG_KUSER_HELPERS=n.
|-
|-
| kernel/criu || FS-notify queues || hard || - || We dump [[Fsnotify]] files, but when they contain events inside -- just ignore those. Need to fetch then and put back on restore. The difficulty here is that while dumping/restoring CRIU may touch files that are monitored and thus produce unwanted events into queue.
| tests || Run many/all tests in "container" || medium || - || Currently we run zdtm tests one-by-one. It would be nice to run the all in one pseudo-container and C/R them as one big subtree.
|-
|-
| crtools || Remove hardcoded TASK_SIZE (at least for AArch32) || medium || cov || Dumping an AArch32 application using an AArch32 CRIU under an AArch64 kernel fails because TASK_SIZE is wrong. If TASK_SIZE were determined at runtime, the process would be able to proceed further. TASK_SIZE could be guessed using uname/cpuinfo and rules, probed with a series of accesses, or perhaps, following the example of PAGE_SIZE, the ELF auxiliary vector should include it.
| tests || [[Fuzz testing|Trinity-like (fuzz) testing]] || hard || - || The existing suite is 99% functionality testing. Need more sophisticated testing -- take a process that has done a random set of actions, C/R one, check that all is OK. The latter is the most complicated thing.
|-
|-
| crtools || Hardcoded PAGE_SIZE (at least for AArch64) || medium || cov || Dumping an AArch64 under an AArch64 kernel with 64K pages fails because PAGE_SIZE is wrong. Many uses of the PAGE_SIZE constant don't actually need an exact page size. Maybe split uses into PAGE_OR_LESS, EXEC_PAGESIZE (max possible for a platform), and page_size (actual value, probably pulled from auxv in memory or /proc or from smaps in /proc).
| crtools || Set checkpoint tokens without recompiling || medium || - || Sometimes you need to call checkpoint in some particular point of the code. The way to do it now is to recompile app with criu_dump() call where needed. But it is quite a bummer to recompile, repackage and redistribute an app you want to c/r. It would be great if one could set a token in app source and then let criu find that point in running task and take a snapshot. The best way to do it might be in libcriu.
|-
|-
| crtools || Make CRIU work on AArch32 with CONFIG_KUSER_HELPERS=n || medium || cov || CRIU currently fails on AArch32 kernels built with CONFIG_KUSER_HELPERS=n.
| crtools || Large ghost files support || medium || - || If we have a large ghost (opened unlinked) file, it's inefficient to copy it to another node via CRIU dump. Need to migrate them independently, iteratively, using memory tracking.
|}
|}
[[Category:Development]]
[[Category:Development]]
[[Category:Plans]]
[[Category:Plans]]