On 03/20/2014 03:29 PM, David Herrmann wrote:
Hi
On Thu, Mar 20, 2014 at 10:01 AM, Pavel Emelyanov xemul@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