On Wed, Jan 29, 2014 at 12:02 AM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: > On 01/28/2014 02:14 PM, Kay Sievers wrote: >>> >>> But yes, alternatively classic systems may be able to get around the >>> issues via tmpfs quotas and convincing applications to use O_TMPFILE >>> there. But to me this seems less ideal then the Android approach, where >>> the lifecycle of the tmpfs fds more limited and clear. >> >> Tmpfs supports no quota, it's all a huge hole and unsafe in that >> regard on every system today. But ashmem and kdbus, as they are today, >> are not better. > > We can fix that aspect in tmpfs. Creating new file objcts outside of > filesystems really doesn't make things any better, since our toolbox > around this stuff largely revolves around filesystems. Sure, it should be fixed, not doubt, even when not in this context, it's something that we should have. Back to the topic, let's say, if we would require a tmpfs mount to get to an unlinked shmemfd, which sounds acceptable if we can solve the other features in a nice way. What would be the interface for additional functionality like sealing/unsealing that thing, that no operation can destruct its content as long as there is more than a single owner? That would be a new syscall or fcntl() with specific shmemfd options? We also need to solve the problem that the inode does not show up in /proc/$PID/fd/, so that nothing can create a new file for it which we don't catch with the "single owner" logic. Or we could determine the "single owner" state from the inode itself? Kay -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>