On 08.10.21 09:25, Rasmus Villemoes wrote:

On 07/10/2021 21.02, John Hubbard wrote:

quoted

On 10/7/21 11:50, Suren Baghdasaryan wrote:
...

quoted

quoted

quoted

quoted

The desire is for one of these two parties to be a human who can get
the data and use it as is without additional conversions.
/proc/$pid/maps could report FD numbers instead of pathnames, which
could be converted to pathnames in userspace. However we do not do
that because pathnames are more convenient for humans to identify a
specific resource. Same logic applies here IMHO.

Yes, please. It really seems like the folks that are interested in this
feature want strings. (I certainly do.) For those not interested in the
feature, it sounds like a CONFIG to keep it away would be sufficient.
Can we just move forward with that?

Would love to if others are ok with this.

If this doesn't get accepted, then another way forward would to continue
the ideas above to their logical conclusion, and create a new file system:
vma-fs.

Or: Why can't the library/application that wants a VMA backed by memory
to have some associated name not just

   fd = open("/run/named-vmas/foobar#24", O_CLOEXEC|O_RDWR|O_EXCL|O_CREAT);
   unlink("/run/named-vmas/foobar#24");
   ftruncate(fd, ...);
   mmap(fd);

where /run/named-vmas is a tmpfs (probably with some per-user/per-app
subdirs). That requires no changes in the kernel at all. Yes, it lacks
the automatic cleanup of using real anon mmap in case there's a crash
between open and unlink, but in an environment like Android that should
be solvable.

I'm going to point out that we already do have names for memfds.

"The name supplied in name is used as a filename and will be displayed 
as  the  target  of  the corresponding  symbolic  link  in  the 
directory /proc/self/fd/." It's also displayed in /proc/self/maps.

So theoretically, without any kernel changes one might be able to 
achieve something as proposed in this patch via memfd_create().

There is one issue to be fixed:

MAP_PRIVATE on memfd results in a double memory consumption on any 
access via the mapping last time I checked (one page for pagecache, one 
page for private mapping).


-- 
Thanks,

David / dhildenb