On 03/20/2014 03:29 PM, David Herrmann wrote: > Hi > > On Thu, Mar 20, 2014 at 10:01 AM, Pavel Emelyanov <xemul at parallels.com> > wrote: >> On 03/20/2014 12:47 PM, Cyrill Gorcunov wrote: >>> If I'm not mistaken in something obvious, this looks similar to >>> /proc/pid/map_files >>> feature, Pavel? >> >> It is, but the map_files will work "in the opposite direction" :) In the >> memfd >> case one first gets an FD, then mmap()s it; in the /proc/pis/map_files case >> one >> should first mmap() a region, then open it via /proc/self/map_files. >> >> But I don't know whether this matters. > > Yes, you can replace memfd_create() so far with: > p = mmap(NULL, size, ..., MAP_ANON | MAP_SHARED, -1, 0); > sprintf(path, "/proc/self/map_files/%lx-%lx", p, p + size); > fd = open(path, O_RDWR); > > However, map_files is only enabled with CONFIG_CHECKPOINT_RESTORE, the > /proc/pid/map_files/ directory is root-only (at least I get EPERM if > non-root),
Yes. But this is something we'd also like to have fixed :) Having two parties willing the same makes it easier for the patch to get accepted. > it doesn't provide the "name" argument which is very handy > for debugging, What if we make mmap's shmem_zero_setup() generate a meaningful name, would it solve the debugging issue? > it doesn't explicitly support sealing (it requires MAP_ANON to be backed > by shmem) Can you elaborate on this? The fd generated by sys_memfd() will be shmem-backed, so will be the file opened via map_files link for the MAP_ANON | MAP_SHARED mapping. So what are the problems to make it support sealing? > and it's a very weird API for something this simple. :) Thanks, Pavel
