Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 19 Oct 2018 21:44:01 -0700 (PDT)
Message-Id: <20181019.214401.2045294780943844999.davem@davemloft.net>
To:     acme@kernel.org
Cc:     linux-kernel@vger.kernel.org, dzickus@redhat.com
Subject: Re: perf overlapping maps...
From:   David Miller <davem@davemloft.net>
In-Reply-To: <20181019.210549.1285253275146712779.davem@davemloft.net>
References: <20181019.210549.1285253275146712779.davem@davemloft.net>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

From: David Miller <davem@davemloft.net>
Date: Fri, 19 Oct 2018 21:05:49 -0700 (PDT)

> One solution I've come up with is:
> 
> 1) When synthesizing a fork event, set PERF_RECORD_MISC_COMM_EXEC in
>    header->misc.
> 
> 2) Use this to elide the map groups clone in
>    thread__clone_map_groups().

Looking into code history, I notice:

commit 363b785f3805a2632eb09a8b430842461c21a640
Author: Don Zickus <dzickus@redhat.com>
Date:   Fri Mar 14 10:43:44 2014 -0400

    perf tools: Speed up thread map generation

and the subsequent:

commit 4aa5f4f7bb8bc41cba15bcd0d80c4fb085027d6b
Author: Arnaldo Carvalho de Melo <acme@redhat.com>
Date:   Fri Feb 27 19:52:10 2015 -0300

    perf tools: Fix FORK after COMM when synthesizing records for pre-existing threads

If Don wanted to have the map cloning to happen for processes without
CLONE_VM, I'm not sure that's right.

For real threads, we just take a reference to the map group from
the parent.

Don, a quick summary.  If we synthesize a fork event, let's say for an
emacs process.  perf will clone the map groups of the parent bash
shell which invoked emacs.  Via:

thread__fork(thread, parent, timestamp)
{
 ...
 thread__clone_map_groups(thread, parent)
 {
   ...
   map_groups__clone(thread, parent->mg)

Which is completely bogus.  It brings all of the bash process maps
into the emacs thread map group.  Then we process the emacs mmap2
events, which overlap the bash process maps already cloned into the
emacs map group.  And this make all kinds of erroneous things happen.

I'm suggesting to elide the map groups clone in this situation where
we are synthesizing the fork.

Thanks.