Re: [patch 2/2] fs, proc: Introduce the /proc/<pid>/map_files/ directory v6

[Pavel Emelyanov <xemul@parallels.com>]

> I'm reluctant to merge something like this unless/until it has real
> use-cases.
> 
> What is the status of your c/r effort?

Working prototype that can dump and restore tree of processes with their
registers, memory of all kinds (anon/file, private/shared), open regular
files and pipes (with contents).

And we have an RFC set from Tejun that can suspend and resume a TCP connection.

> What additional kernel patches are required to bring that effort to a
> usable state and where are those patches?

* The one you've already accepted with ->statfs for pipefs.
* PTRACE_SEIZE set from Tejun (RFC was sent some time earlier)
* CLONE_USEPID flag for the clone() syscall (Cyrill will re-send a bit later)
* The binfmt handler for images (I've sent it earlier, but there's a discussion
  happening over it. We can do restore without one, but it will improve the
  situation significantly)

Once this is merged the prototype I described above starts working on the
out-of-the-box kernel.

> IOW, before starting to merge things I'd like to get an understanding
> of what *all* the patches look like and of what level of c/r
> functionality they provide.
> 
> This particular patch introduces a distressing amount of duplication of
> /proc/pid/maps.  The changelog should provide a really good
> justification for doing this: why is /proc/pid/maps (and smaps!)
> unsuitable and why cannot maps/smaps be fixed to be suitable?

This is not duplication, since with /proc/pid/s?maps you have no idea of what
file is being mapped by a vma. I mean - you know some "path" to it, but it's
not reliable at all.

Besides, without this set there's absolutely no way to find out which two 
mappings are shared and is extremely hard to restore shared mapping.

Thanks,
Pavel