A feature being unsupported for checkpoint/restart could mean two things. It could mean that checkpoint on an application using the feature will fail. For instance, if an application has an open fd on an unsupported device or on a file of an unsupported fs, then checkpoint will fail with an informative error message. That is ok.
It could also mean that checkpoint will 'succeed', but restart will fail. Worse, it could mean that restart will 'succeed', but the application will misbehave after restart. For instance, we currently do not address mounts. So if an application has done 'mount(FILE1, FILE2, NULL, MS_BIND, 0)' before being checkpointed, then after restart FILE1 may no longer be bind-mounted onto FILE2.
What is implemented (maybe these should be in a more sensible order :)
* open regular files and directories: * ext2, ext3, ext4 * /dev/null, zero, random, urandom * epoll fd's * unix sockets * ipv4 sockets (except lingering sockets) * SYSV IPC (message queues, semaphores, and shared memory) * except semaphore undo * Unix98 ptys * eventfd * futexes * process ids * credentials (userid, group, and POSIX capabilities) * Smack LSM labels * pipes * FIFOs * signals * multiple processes, threads * nested namespaces of: * user * IPC * UTS (hostname) * IPC * (nested pid namespaces only require userspace support) * timerfd * signalfd
What is NOT implemented (please make each a link to a page describing issues, a design for solving, how we will detect it to refuse checkpoint if we will not support it, and "how ugly it will make the kernel")
* mounts * network devices * unlinked files * inotify * SYSV IPC: semaphore undo * netlink * file locks * file leases * fowner+sigio * ptraced tasks * time namespace