From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934725AbcALKju (ORCPT ); Tue, 12 Jan 2016 05:39:50 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:33460 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752262AbcALKjr (ORCPT ); Tue, 12 Jan 2016 05:39:47 -0500 Date: Tue, 12 Jan 2016 11:39:43 +0100 From: Ingo Molnar To: Peter Zijlstra Cc: Arnaldo Carvalho de Melo , Stephane Eranian , Namhyung Kim , LKML , Jiri Olsa , Namhyung Kim , Adrian Hunter , "ak@linux.intel.com" Subject: Re: [RFC] perf record: missing buildid for callstack modules Message-ID: <20160112103943.GA6310@gmail.com> References: <20160107215945.GA19314@kernel.org> <80F05A66-6943-499A-B402-96249953CD15@gmail.com> <20160107234746.GB19314@kernel.org> <20160108181942.GB20576@kernel.org> <20160111173036.GA6344@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160111173036.GA6344@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Peter Zijlstra wrote: > On Fri, Jan 08, 2016 at 03:19:42PM -0300, Arnaldo Carvalho de Melo wrote: > > > We already discussed how to solve it, and it involves extending once more > > PERF_RECORD_MMAP, so that, when we load a DSO we stash its build-id in a > > per-DSO data structure in the kernel, then, when generating PERF_RECORD_MMAP3 > > we put the buildid there, this way if any of those binaries gets replaced > > while we're recording samples, we would notice, i.e. we wouldn't care that > > much about the pathname, looking everything by the content based buildid > > instead. > > Does the kernel even know about the buildid crap? AFAIK the binfmt stuff doesn't > know or care about things like that. Heck, we support binfmts that do not even > have a buildid. The kernel's exec() code does not care about the past, it will execute whatever is fit to execute right now. But perf tooling cares very much: it can lead to subtle bugs and bad data if we display a profile with the wrong DSO or binary. 'Bad' profiles resulting out of binary mismatch can be very convincing and can send developers down the wrong path for hours. I'd expect my tooling to not do that. Path names alone (the thing that exec() cares about) are not unique enough to identify the binary that was profiled. So we need a content hash - hence the build-ID. Can you suggest a better solution than a build-time calculated content hash? As for binary formats that suck and don't allow for a content hash: we do our best, but of course the risk of data mismatch is there. We could perhaps cache the binary inode's mtime field to at least produce a 'profile data is older than binary/DSO modification date!' warning. (Which check won't catch all cases, like cross-system profiling data matches.) Thanks, Ingo