Date: Thu, 21 Apr 2016 12:42:48 -0300
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>, Ingo Molnar <mingo@kernel.org>,
        Adrian Hunter <adrian.hunter@intel.com>,
        Brendan Gregg <brendan.d.gregg@gmail.com>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Alexei Starovoitov <ast@kernel.org>, David Ahern <dsahern@gmail.com>,
        He Kuang <hekuang@huawei.com>, Jiri Olsa <jolsa@redhat.com>,
        Masami Hiramatsu <mhiramat@kernel.org>,
        Milian Wolff <milian.wolff@kdab.com>,
        Namhyung Kim <namhyung@kernel.org>,
        Stephane Eranian <eranian@google.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Vince Weaver <vincent.weaver@maine.edu>,
        Wang Nan <wangnan0@huawei.com>, Zefan Li <lizefan@huawei.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH/RFC] perf core: Allow setting up max frame stack depth
 via sysctl
Message-ID: <20160421154248.GC3677@kernel.org>
References: <20160420224730.GX3677@kernel.org>
 <20160421104858.GH3408@twins.programming.kicks-ass.net>
 <20160421151707.GB3677@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160421151707.GB3677@kernel.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2873
Lines: 56

Em Thu, Apr 21, 2016 at 12:17:07PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Apr 21, 2016 at 12:48:58PM +0200, Peter Zijlstra escreveu:
> > On Wed, Apr 20, 2016 at 07:47:30PM -0300, Arnaldo Carvalho de Melo wrote:
> > > +++ b/kernel/events/callchain.c
> 
> > > @@ -73,7 +81,7 @@ static int alloc_callchain_buffers(void)
> > >  	if (!entries)
> > >  		return -ENOMEM;

> > > -	size = sizeof(struct perf_callchain_entry) * PERF_NR_CONTEXTS;
> > > +	size = perf_callchain_entry__sizeof() * PERF_NR_CONTEXTS;

> > >  	for_each_possible_cpu(cpu) {
> > >  		entries->cpu_entries[cpu] = kmalloc_node(size, GFP_KERNEL,

> > And this alloc _will_ fail if you put in a decent sized value..

> > Should we put in a dmesg WARN if this alloc fails and
> > perf_event_max_stack is 'large' ?
> 
> Unsure, it already returns -ENOMEM, see, some lines above, i.e. it
> better have error handling up this, ho-hum, call chain, I'm checking...
  
So, it is, using the tools, since it fits this bill:

[root@jouet acme]# perf probe get_callchain_buffers
Added new event:
  probe:get_callchain_buffers (on get_callchain_buffers)

You can now use it in all perf tools, such as:

	perf record -e probe:get_callchain_buffers -aR sleep 1

[root@jouet acme]# perf trace -e perf_event_open --event probe:get_callchain_buffers/call-graph=fp/ -- perf record -g usleep 1
[ perf record: Woken up 1 times to write data ]
    26.740 ( 0.008 ms): perf/1264 perf_event_open(attr_uptr: 0x1e6b618, pid: 1265, group_fd: -1, flags: FD_CLOEXEC) ...
    26.740 (         ): probe:get_callchain_buffers:(ffffffff811a9480))
                                       get_callchain_buffers+0xfe200001 ([kernel.kallsyms])
                                       SYSC_perf_event_open+0xfe2003bc ([kernel.kallsyms])
                                       sys_perf_event_open+0xfe200009 ([kernel.kallsyms])
                                       do_syscall_64+0xfe200062 ([kernel.kallsyms])
                                       return_from_SYSCALL_64+0xfe200000 ([kernel.kallsyms])
                                       syscall+0xffff0179d3c22019 (/usr/lib64/libc-2.22.so)
                                       cmd_record+0xffffffffff8005fc (/home/acme/bin/perf)
                                       run_builtin+0xffffffffff800061 (/home/acme/bin/perf)
                                       main+0xffffffffff800672 (/home/acme/bin/perf)
                                       __libc_start_main+0xffff0179d3c220f0 (/usr/lib64/libc-2.22.so)
    26.749 ( 0.016 ms): perf/1264  ... [continued]: perf_event_open()) = 4
<SNIP the perf_event_open syscalls for the other 3 CPUs in this system)

So, if we put some too big value there and the allocation fails, people asking
for callchains will get that -ENOMEM back in their face.

I'll do this test, i.e. put some huge value there and ask for callchains...

- Arnaldo