[RFC] shmgetfd idea

[John Stultz <john.stultz@linaro.org>]

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>