Theoretically, you could achieve [memfd_create()] behavior without introducing new syscalls, like this:
int fd = open("/tmp", O_RDWR | O_TMPFILE | O_EXCL, S_IRWXU);
(Note, to more portably guarantee a tmpfs here, we can use "/dev/shm" instead of "/tmp").
Therefore, the most important question is why the hell do we need a third way?
- The backing-memory is accounted to the process that owns the file and is not subject to mount-quotas.
^ Am I right in thinking the first part of this sentence cannot be relied on?
The memfd_create() code is literally implemented as an "unlinked file living in [a] tmpfs which must be kernel internal". Tracing the code, I understand it differs in not implementing LSM checks, also memfds are created to support "seals", as the blog post goes on to explain. However, I'm extremely sceptical that memfds are accounted differently to a tmpfile in principle.
Specifically, when the OOM-killer comes knocking, I don't think it will account for memory held by memfds. This could total up to 50% of RAM - the value of the size= option for tmpfs. The kernel doesn't set a different value for the internal tmpfs, so it would use the default size of 50%.
So I think we can generally expect processes which hold a large memfd, but no other significant memory allocations, will not be OOM-killed. Is that correct?