[CRIU] memfd_create support

[Nicolas Viennot]

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.

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?

Thanks,
Nico