From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754023AbdFWO1b (ORCPT ); Fri, 23 Jun 2017 10:27:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:44584 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752006AbdFWO1a (ORCPT ); Fri, 23 Jun 2017 10:27:30 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F0D5B217C5 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=acme@kernel.org Date: Fri, 23 Jun 2017 11:27:25 -0300 From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Ingo Molnar , Peter Zijlstra , Jiri Olsa , LKML , kernel-team@lge.com, Masami Hiramatsu , Andi Kleen , Adrian Hunter , Wang Nan Subject: Re: [PATCH/RFC 5/9] perf symbols: Fixup the end address of kernel map properly Message-ID: <20170623142725.GD4622@kernel.org> References: <20170623054827.3828-1-namhyung@kernel.org> <20170623054827.3828-6-namhyung@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170623054827.3828-6-namhyung@kernel.org> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Em Fri, Jun 23, 2017 at 02:48:23PM +0900, Namhyung Kim escreveu: > When /proc/kallsyms is used for kernel address, addresses in module can > be changed when the module is reloaded. So if one did perf record with > some module and then for some reason reload the module. Then perf > report might see a different address for the module and the output can > show incorrect symbols. If we, as mentioned in another message, make sure that no module reload is performed while perf record is running, and then refuse to use kallsyms if the buildid for the running module is different from the one in the perf.data build id header, then this is solved, no? > For example, let a module XXX was loaded at 0xffffffff8a000000, the > /proc/kallsyms might show following: > > ... > 0xffffffff81234560 t last_symbol_in_vmlinux > 0xffffffff8a000000 t first_symbol_in_XXX > ... > > As kallsyms fixs up the symbol and map address by using next address, > the end address of last_symbol and kernel map would be start address of > XXX (0xffffffff8a000000). And samples in 0xffffffff8a001234 can be > found in a map for XXX module. > > But later, XXX was reloaded at 0xffffffff8a007000, slightly higher than > before. Now reading /proc/kallsyms tells that the end address of last > symbol would be 0xfffffff8a007000 and so kernel map is same. Now > samples in 0xffffffff8a001234 - formerly in the XXX module - would go to > the kernel map and show no symbols. > > In this case, perf can know the address of map of XXX from mmap event in > perf.data so it can adjust kernel map address using the address of XXX > map. To do that, replace map__fixup_end() by __map_groups__fixup_end(). > This still have incorrect end address of last symbol in the kernel map > but it's ok since samples in that address wouldn't go to the kernel map > anyway. > > Cc: Adrian Hunter > Cc: Wang Nan > Signed-off-by: Namhyung Kim > --- > tools/perf/util/symbol.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c > index 74078ba595b3..ce79a51f25bf 100644 > --- a/tools/perf/util/symbol.c > +++ b/tools/perf/util/symbol.c > @@ -1832,7 +1832,7 @@ static int dso__load_kernel_sym(struct dso *dso, struct map *map) > dso->binary_type = DSO_BINARY_TYPE__KALLSYMS; > dso__set_long_name(dso, DSO__NAME_KALLSYMS, false); > map__fixup_start(map); > - map__fixup_end(map); > + __map_groups__fixup_end(map->groups, map->type); > } > > return err; > @@ -1880,7 +1880,7 @@ static int dso__load_guest_kernel_sym(struct dso *dso, struct map *map) > machine__mmap_name(machine, path, sizeof(path)); > dso__set_long_name(dso, strdup(path), true); > map__fixup_start(map); > - map__fixup_end(map); > + __map_groups__fixup_end(map->groups, map->type); > } > > return err; > -- > 2.13.1