From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Emelyanov Subject: Re: [PATCH 3/6] shm: add memfd_create() syscall Date: Thu, 20 Mar 2014 15:50:30 +0400 Message-ID: <532AD606.40406@parallels.com> References: <1395256011-2423-1-git-send-email-dh.herrmann@gmail.com> <1395256011-2423-4-git-send-email-dh.herrmann@gmail.com> <20140320084748.GK1728@moon> <532AAE7B.2030501@parallels.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: Cyrill Gorcunov , linux-kernel , Hugh Dickins , Alexander Viro , Karol Lewandowski , Kay Sievers , Daniel Mack , Lennart Poettering , =?ISO-8859-1?Q?Kristian_H?= =?ISO-8859-1?Q?=F8gsberg?= , John Stultz , Greg Kroah-Hartman , Tejun Heo , Johannes Weiner , "dri-devel@lists.freedesktop.org" , linux-fsdevel , linux-mm , Andrew Morton , Linus Torvalds , Ryan Lortie , "Michael Kerrisk (man-pages)" To: David Herrmann Return-path: In-Reply-To: Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On 03/20/2014 03:29 PM, David Herrmann wrote: > Hi > > On Thu, Mar 20, 2014 at 10:01 AM, Pavel Emelyanov 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org