On Tue, Jan 27, 2015 at 11:50:49AM -0800, Kees Cook wrote: > > + > > +The main purpose of map_files directory is to be able to retrieve a set of > > +memory mapped files in a fast way instead of parsing /proc/<pid>/maps or > > +/proc/<pid>/smaps which contain a way more records. Same time one can > > open(2) > > +mappings from the listings of two processes and comparing inodes figure out > > +which anonymous memory areas are actually shared. > > Thanks for details! I still don't understand how this is used for > checkpoint/restore when the mmap offset isn't shown. Can't a process > map, say 4K of a file, from different offsets, and it would show up > as: > > 400000-401000 -> /some/file > 401000-402000 -> /some/file > > but there'd be no way to know how to restore that mapping?
In criu we use a few sources of information (ie we scan not only map_files, but have to use /proc/pid/smaps as well which has offset for mapping). So at the end we have all picture under our hands. > Are these symlinks "regular" symlinks, or are they something more > special that bypasses VFS? If it bypasses VFS, I think adding and open > check with PTRACE_ATTACH is needed, since now you're able to _modify_ > the memory space of the target process instead of just reading it. Opening them goes same way as open of /proc/pid/fd/ entries as far as I can tell. This should be enough, or I miss something obvious here? Otherwise opening /proc/pid/fd/ should use PTRACE_ATTACH instead of PTRACE_MODE_READ (as in proc_fd_access_allowed). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
