Re: [RFC] perf: mmap2 not covering VM_CLONE regions

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Oct 08, 2013 at 11:42:06AM +0200, Stephane Eranian wrote:
> On Tue, Oct 8, 2013 at 11:36 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Tue, Oct 08, 2013 at 09:15:30AM +0200, Stephane Eranian wrote:
> >> Yes, it is but I am trying to see whether or not we could unify that and
> >> use a single u64 number to uniquely identify each mapping.
> >
> > No you cannot; two unrelated executables which have distinct mm_ids can
> > easily mmap() the same shared file.
> 
> That seems to indicate the mm_ids is not attached to the right level of VM
> data structure. 

No that's not it.. shared mappings can create arbitrary couplings
between mm's, there's really nothing you can do about that.

This is really only about anonymous memory shared with CLONE_VM.

> But I am okay with keeping it that way and stashing the mm_id
> as a pseudo inode number for the case of non file-backed mappings. If we
> say maj=min=ino=gen=0 means no "info", then any other combinations can
> be used to identify identical mappings. We use actual min,maj, ino, gen
> for file backed, and maj=min=gen=0 + ino = mm_ids for the other cases.
> That should work, shouldn't it?

I'm not sure if min=maj=0 is a valid device, nor do I know if ino=0 is a
valid ino. But I suppose the name "//anon" should be a big enough clue
if both of those fail.