In working with ashmem and looking briefly at kdbus' memfd ideas, there's a commonality that both basically act as a method to provide applications with unlinked tmpfs/shmem fds. In the Android case, its important to have this interface to atomically provide these unlinked tmpfs fds, because they'd like to avoid having tmpfs mounts that are writable by applications (since that creates a potential DOS on the system by applications writing random files that persist after the process has been killed). It also provides better life-cycle management for resources, since as the fds never have named links in the filesystem, their resources are automatically cleaned up when the last process with the fd dies, and there's no potential races between create and unlink with processes being terminated, which avoids the need for cleanup management. I won't speak for the kdbus use, but my understanding is memfds address similar needs along with being something to connect with other features. So one idea was maybe we need a new interface. Something like: int shmgetfd(char* name, size_t size, int shmflg); Basically this would be very similar to shmget, but would return a file descriptor which could be mapped and passed to other processes to map. Basically very similar to the in-kernel shmem_file_setup() interface. (Thanks to Akashi-san for initially pointing out the similarity to shmget.) Of course, shmgetfd on its own wouldn't address the quota issue right away, but it would be fairly easy have a limit for the total number of bytes a process could generate, or some other limiting mechanism. The probably more major drawback here is that both ashmem and memfd tack on additional features that can be done to the fds. In ashmems' case it allows for changing the segment's name, and unpinning regions which can then be lazily discarded by the kernel. For memfd, the extra feature is sealing, which prevents modification of the file when its shared. In ashmem's case, both vma-naming and volatile ranges are trying to address how the needed features would be generically applied to tmpfs fds (as well as potentially wider uses as well) - so with something like shmgetfd it would provide all the functionality needed. I am not aware of any current plans for memfd's sealing to be similarly worked into a generic concept - the code hasn't even been submitted, so this is too early - but in any case, its important to note none of these plans for generic functionality have been merged or even received with much interest, so I do understand how a proposal for a new interface that only solves half of the needed infrastructure may not be particularly welcome. So while I do understand the difficulty of trying to create more generic interfaces rather then just creating a new chardev/ioctl interface to a more limited subset of functionality, I do think its worth exploring if we can find a way to share infrastructure at some level (even if its just due-diligence to prove if the more limited scope chardev/ioctl interfaces are widely agreed to be better). Anyway, I just wanted to submit this sketched out idea as food for thought to see if there was any objection or interest (I've got a draft patch I'll send out once I get a chance to test it). So let me know if you have any feedback or comments. thanks -john -- 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>