Abstract
CRIU (Checkpoint/Restore in Userspace) allows you to stop (checkpoint)
an application/container and save its state to disk. Using that state,
you can restart (restore) that application/container (even on a
different machine).
In order for CRIU to correctly checkpoint/restore a process (or
container) it needs to dump all file descriptors that the process has
open. Thus, it also needs to dump information about all the mounts these
fds are on.
However, if the fd is on a mount that has been "unmounted" (umount2(mnt,
MNT_DETACH)). We can't get information about the mount from
/proc/$pid/mountinfo. I (with a lot of help from a lot of people) worked
on worked on adding a new flag STATMOUNT_BY_FD to the statmount()
syscall to export mount info for unmounted mounts. It is a part of the
upcoming v7.0 kernel release [1].
I would like to talk about the design considerations and challenges we
faced when working on both the kernel and CRIU side.
Outline of Key Points
* What is CRIU?
* Challenges CRIU faces to get information it needs from the kernel
* Problem Statement
* Other Approaches Considered
* STATMOUNT_BY_FD implementation considerations
* CRIU implementation details
* Future Work
Duration of this Talk
Lightining Talk (I should be able to cover everything in 10 minutes)
I gave a version of this talk at the Checkpoint/Restore microconference
at LPC last year [2].
Short Bio
I am a Software Engineering Intern at Cedana and a final year student at
IIIT Naya Raipur. I have been working with the CRIU project on/off for
the past two years mostly as a part of Google Summer of Code 2024 and
2025. I am an inexperienced kernel dev and have worked on the kernel to
add features required by CRIU. This talk is about work I did as a part
of Google Summer of Code 2025.
[1]:
https://lwn.net/Articles/1057769/
[2]:
https://lpc.events/event/19/contributions/2240/