From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752595AbbKZHnq (ORCPT ); Thu, 26 Nov 2015 02:43:46 -0500 Received: from mail-wm0-f48.google.com ([74.125.82.48]:33822 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752026AbbKZHno (ORCPT ); Thu, 26 Nov 2015 02:43:44 -0500 Date: Thu, 26 Nov 2015 08:43:35 +0100 From: Ingo Molnar To: Namhyung Kim Cc: Arnaldo Carvalho de Melo , Peter Zijlstra , Jiri Olsa , LKML , David Ahern , Kan Liang , Frederic Weisbecker , Andi Kleen , Wang Nan Subject: Re: [PATCH 2/3] perf callchain: Stop resolving callchains after invalid address Message-ID: <20151126074335.GA18742@gmail.com> References: <1448521700-32062-1-git-send-email-namhyung@kernel.org> <1448521700-32062-2-git-send-email-namhyung@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1448521700-32062-2-git-send-email-namhyung@kernel.org> 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 * Namhyung Kim wrote: > Unwinding optimized binaries using frame pointer gives garbage. Check > callchain address and stop if it's under vm.mmap_min_addr sysctl value. > > Before: > $ perf report --stdio --no-children -g callee > ... > > 1.37% perf [kernel.vmlinux] [k] smp_call_function_single > | > ---smp_call_function_single > _perf_event_enable > perf_event_for_each_child > perf_ioctl > do_vfs_ioctl > sys_ioctl > entry_SYSCALL_64_fastpath > __GI___ioctl > 0 > 0 > 0x1c5aa70 > 0x1c5b910 > 0x1c5aa70 > 0x1c5b910 > 0x1c5aa70 > 0x1c5b910 > 0x1c5aa70 > 0x1c5b910 > 0x1c5aa70 > 0x1c5b910 > ... > > After: > $ perf report --stdio --no-children -g callee > ... > > 1.37% perf [kernel.vmlinux] [k] smp_call_function_single > | > ---smp_call_function_single > _perf_event_enable > perf_event_for_each_child > perf_ioctl > do_vfs_ioctl > sys_ioctl > entry_SYSCALL_64_fastpath > __GI___ioctl In addition to that, would it make sense to terminate the callchain with an indicator that we found something anomalous? Such an extra line: ... would not be intrusive, but would tell the informed reader that it's not a normal ending of the call chain. This assumes that we can tell apart 'normal end of call chain' from 'seems to end with garbage poiner' cases - can do we that? Thanks, Ingo