[CRIU] memfd_create support

[Andrei Vagin]

On Tue, Dec 10, 2019 at 01:44:22AM +0000, Nicolas Viennot wrote:
> Dear all,
> 
> I am trying to add checkpoint-restore (C/R) support for memfd_create().
> 
> A few observations:
> - the file descriptor (fd) that is returned by memfd_create() appears to CRIU as
>   regular file that is unlinked (ghost file). The file name listed by the link
>   of /proc/<pid>/fd/<n> has the form "/memfd:<name>".
> - The "/" prefix creates an ambiguity with a file created with open() that would
>   also be called "/memfd:xxx". However, the mnt_id of the memfd file does not
>   appear in the list of mounts from /proc/<pid>/mountinfo (CRIU's
>   lookup_mnt_id() fails), and its statfs type is either TMPFS_MAGIC or
>   HUGETLBFS_MAGIC. This can be used to resolve the ambiguity.
> - The name passed to memfd_create() is not a global: two different memfd files
>   can have the same path, and yet be unrelated. The inodes must be used to
>   distinguish memfd files.
> - The fd can be mmaped either with MAP_SHARED or MAP_PRIVATE. We can reuse the
>   ghost file logic or shmem.c logic, which opens /proc/<pid>/map_files to
>   recover the underlying fd.
> 
> 1) What's the best way to implement C/R for memfd_create()?
> In the image, should we rely on the ghost file mechanism of files-reg, or
> should we create a new file type (similar to signalfd)? Note that we'll have to
> store the MFD_HUGETLB flag somewhere.

I think we have to create a new file type.

> 
> On a related note, In the current CRIU implementation, (MAP_ANONYMOUS |
> MAP_SHARED) vmas are handled differently than the MAP_SHARED ones backed by a
> file that has been deleted. In both cases, the implementation opens
> proc/pid/map_files/vma to access the content of the region to dump it. The
> latter is treated as a ghost file, while the former is be treated as a shmem
> file. It seems extra work. 2) Why not support (MAP_ANONYMOUS | MAP_SHARED)
> vmas with ghost files and remove the shmem.c code?

* There is some difference in how shmem files and ghost files are
  restored.

* Shared memory can be migrated iteratively (this isn't implemented
  yet).
https://criu.org/Memory_changes_tracking

> 
> Thanks,
> Nico
> 
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu