From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vk0-x22e.google.com ([IPv6:2607:f8b0:400c:c05::22e]:33509 "EHLO mail-vk0-x22e.google.com" rhost-flags-OK-OK-OK-OK) by eddie.linux-mips.org with ESMTP id S23992126AbdCOUHR2kH1L (ORCPT ); Wed, 15 Mar 2017 21:07:17 +0100 Received: by mail-vk0-x22e.google.com with SMTP id d188so13785644vka.0 for ; Wed, 15 Mar 2017 13:07:17 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20170315194447.scsf3fiwvf7z5gzc@arch-dev> References: <20170315194447.scsf3fiwvf7z5gzc@arch-dev> From: Andy Lutomirski Date: Wed, 15 Mar 2017 13:06:50 -0700 Message-ID: Subject: Re: [RFC PATCH 00/13] Introduce first class virtual address spaces Content-Type: text/plain; charset=UTF-8 Return-Path: Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-subscribe: List-owner: List-post: List-archive: To: Andy Lutomirski , Andy Lutomirski , Till Smejkal , Richard Henderson , Ivan Kokshaysky , Matt Turner , Vineet Gupta , Russell King , Catalin Marinas , Will Deacon , Steven Miao , Richard Kuo , Tony Luck , Fenghua Yu , James Hogan , Ralf Baechle , "James E.J. Bottomley" , Helge Deller , Benjamin Herrenschmidt , Paul Mackerras , Michael Ellerman , Martin Schwidefsky , Heiko Carstens , Yoshinori Sato , Rich Felker , "David S. Miller" , Chris Metcalf , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , X86 ML , Chris Zankel , Max Filippov , Arnd Bergmann , Greg Kroah-Hartman , Laurent Pinchart , Mauro Carvalho Chehab , Pawel Osciak , Marek Szyprowski , Kyungmin Park , David Woodhouse , Brian Norris , Boris Brezillon , Marek Vasut , Richard Weinberger , Cyrille Pitchen , Felipe Balbi , Alexander Viro , Benjamin LaHaise , Nadia Yvette Chambers , Jeff Layton , "J. Bruce Fields" , Peter Zijlstra , Hugh Dickins , Arnaldo Carvalho de Melo , Alexander Shishkin , Jaroslav Kysela , Takashi Iwai , "linux-kernel@vger.kernel.org" , linux-alpha@vger.kernel.org, arcml , "linux-arm-kernel@lists.infradead.org" , adi-buildroot-devel@lists.sourceforge.net, linux-hexagon@vger.kernel.org, "linux-ia64@vger.kernel.org" , linux-metag@vger.kernel.org, Linux MIPS Mailing List , linux-parisc@vger.kernel.org, linuxppc-dev , "linux-s390@vger.kernel.org" , "linux-sh@vger.kernel.org" , sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, Linux Media Mailing List , linux-mtd@lists.infradead.org, USB list , Linux FS Devel , linux-aio@kvack.org, "linux-mm@kvack.org" , Linux API , linux-arch , ALSA development Message-ID: <20170315200650.DtbFCx-GTvFZvyB8vy7_FXeYY-FZJZcUC2GZeQHt3iY@z> On Wed, Mar 15, 2017 at 12:44 PM, Till Smejkal wrote: > On Wed, 15 Mar 2017, Andy Lutomirski wrote: >> > One advantage of VAS segments is that they can be globally queried by user programs >> > which means that VAS segments can be shared by applications that not necessarily have >> > to be related. If I am not mistaken, MAP_SHARED of pure in memory data will only work >> > if the tasks that share the memory region are related (aka. have a common parent that >> > initialized the shared mapping). Otherwise, the shared mapping have to be backed by a >> > file. >> >> What's wrong with memfd_create()? >> >> > VAS segments on the other side allow sharing of pure in memory data by >> > arbitrary related tasks without the need of a file. This becomes especially >> > interesting if one combines VAS segments with non-volatile memory since one can keep >> > data structures in the NVM and still be able to share them between multiple tasks. >> >> What's wrong with regular mmap? > > I never wanted to say that there is something wrong with regular mmap. We just > figured that with VAS segments you could remove the need to mmap your shared data but > instead can keep everything purely in memory. memfd does that. > > Unfortunately, I am not at full speed with memfds. Is my understanding correct that > if the last user of such a file descriptor closes it, the corresponding memory is > freed? Accordingly, memfd cannot be used to keep data in memory while no program is > currently using it, can it? No, stop right here. If you want to have a bunch of memory that outlives the program that allocates it, use a filesystem (tmpfs, hugetlbfs, ext4, whatever). Don't create new persistent kernel things. > VAS segments on the other side would provide a functionality to > achieve the same without the need of any mounted filesystem. However, I agree, that > this is just a small advantage compared to what can already be achieved with the > existing functionality provided by the Linux kernel. I see this "small advantage" as "resource leak and security problem". >> This sounds complicated and fragile. What happens if a heuristically >> shared region coincides with a region in the "first class address >> space" being selected? > > If such a conflict happens, the task cannot use the first class address space and the > corresponding system call will return an error. However, with the current available > virtual address space size that programs can use, such conflicts are probably rare. A bug that hits 1% of the time is often worse than one that hits 100% of the time because debugging it is miserable. --Andy