Re: [PATCH v10 3/3] mm: add anonymous vma name refcounting

[John Hubbard]

On 10/7/21 11:50, Suren Baghdasaryan wrote:
...
> > > > > > > > > > I believe Pavel meant something as simple as
> > > > > > > > > > $ YOUR_FILE=$YOUR_IDS_DIR/my_string_name
> > > > > > > > > > $ touch $YOUR_FILE
> > > > > > > > > > $ stat -c %i $YOUR_FILE
> > > > > > >
> > > > > > > Ah, ok, now I understand the proposal. Thanks for the clarification!
> > > > > > > So, this would use filesystem as a directory for inode->name mappings.
> > > > > > > One rough edge for me is that the consumer would still need to parse
> > > > > > > /proc/$pid/maps and convert [anon:inode] into [anon:name] instead of
> > > > > > > just dumping the content for the user. Would it be acceptable if we
> > > > > > > require the ID provided by prctl() to always be a valid inode and
> > > > > > > show_map_vma() would do the inode-to-filename conversion when
> > > > > > > generating maps/smaps files? I know that inode->dentry is not
> > > > > > > one-to-one mapping but we can simply output the first dentry name.
> > > > > > > WDYT?
> > > > > >
> > > > > > No. You do not want to dictate any particular way of the mapping. The
> > > > > > above is just one way to do that without developing any actual mapping
> > > > > > yourself. You just use a filesystem for that. Kernel doesn't and
> > > > > > shouldn't understand the meaning of those numbers. It has no business in
> > > > > > that.
> > > > > >
> > > > > > In a way this would be pushing policy into the kernel.
> > > > >
> > > > > I can see your point. Any other ideas on how to prevent tools from
> > > > > doing this id-to-name conversion themselves?
> > > >
> > > > I really fail to understand why you really want to prevent them from that.
> > > > Really, the whole thing is just a cookie that kernel maintains for memory
> > > > mappings so that two parties can understand what the meaning of that
> > > > mapping is from a higher level. They both have to agree on the naming
> > > > but the kernel shouldn't dictate any specific convention because the
> > > > kernel _doesn't_ _care_. These things are not really anything actionable
> > > > for the kernel. It is just a metadata.
> > >
> > > 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.  Like debug-fs and other special file systems, similar policy and
motivation. Also protected by a CONFIG option.

Actually this seems at least as natural as the procfs approach, especially
given the nature of these strings, which feel more like dir+file names, than
simple strings.

thanks,
--
John Hubbard
NVIDIA