Re: [PATCH v5 2/2] mm: add a field to store names for private anonymous memory

[Colin Cross <ccross@google.com>]

On Thu, Aug 20, 2020 at 3:15 PM Cyrill Gorcunov <gorcunov@gmail.com> wrote:
>
> On Thu, Aug 20, 2020 at 02:45:27PM -0700, Colin Cross wrote:
> > >
> > > Guys, could you please enlighen me, I don't understand -- we pass some
> > > random user-space pointer and save it in vm_area_struct then in procfs
> > > we treat it as "string" and print out? What prevents me to put some crap
> > > here then unmap this pointer the kernel will cause page fault in procfs
> > > output (in best scenario)?
> >
> > This is the same pattern used for /proc/pid/cmdline.
> > acccess_remote_vm handles addresses in unmapped pages, it will return
> > 0 if no bytes were readable.
>
> Yes, been in this part of code too long ago, managed to forget. You know
> I'm wondering do we really need a human readable names here? Maybe it would
> be more convenient to keep say u64 number instead? This would eliminate
> need to access VM at all. From user space point of view there should be
> no difference how to recognize such VMAs (by name or by some ID). Or there
> some need for string solely?

Numbers instead of strings would require some central registry to
decode them, which would make it much harder to use.  You can see some
examples of how Android uses it at https://pastebin.com/BQZ1vZnJ for
the cat proces and https://pastebin.com/YNUTvZyz for an ART process.
We label individual stacks with their TIDs (useful since the stack TID
annotation was reverted in 65376df582174ffcec9e6471bf5b0dd79ba05e4a),
the various heaps created by different allocators, and much more.  The
data is consumed manually for debugging, as well as by various memory
stats collection and analysis tools.