From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753091AbbGOOzl (ORCPT ); Wed, 15 Jul 2015 10:55:41 -0400 Received: from smtprelay0211.hostedemail.com ([216.40.44.211]:41493 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751922AbbGOOzj (ORCPT ); Wed, 15 Jul 2015 10:55:39 -0400 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,rostedt@goodmis.org,:::::::::::::::::,RULES_HIT:41:355:379:541:599:800:960:968:973:988:989:1260:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1541:1593:1594:1711:1730:1747:1777:1792:2393:2553:2559:2562:2692:2693:3138:3139:3140:3141:3142:3353:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:4250:4321:4362:4605:5007:6119:6120:6261:7875:7903:8603:9010:10004:10400:10848:10967:11026:11232:11658:11914:12517:12519:12555:12740:13069:13311:13357:21060:21080,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0 X-HE-Tag: stop17_1414e9bdfd423 X-Filterd-Recvd-Size: 2692 Date: Wed, 15 Jul 2015 10:55:36 -0400 From: Steven Rostedt To: AKASHI Takahiro Cc: Jungseok Lee , catalin.marinas@arm.com, will.deacon@arm.com, olof@lixom.net, broonie@kernel.org, david.griego@linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RFC 2/3] arm64: refactor save_stack_trace() Message-ID: <20150715105536.42949ea9@gandalf.local.home> In-Reply-To: <55A646EE.6030402@linaro.org> References: <1436765375-7119-1-git-send-email-takahiro.akashi@linaro.org> <1436765375-7119-3-git-send-email-takahiro.akashi@linaro.org> <20150714093154.4d73e551@gandalf.local.home> <55A5A75A.1060401@linaro.org> <20150714225105.6c1e4f15@gandalf.local.home> <55A646EE.6030402@linaro.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 15 Jul 2015 20:41:34 +0900 AKASHI Takahiro wrote: > Thank you for the explanation. But what I don't really understand here > is why we need to add the "current function" to the stack dump list > returned by save_stack_trace(): > > In check_stack(), > > /* > > * Add the passed in ip from the function tracer. > > * Searching for this on the stack will skip over > > * most of the overhead from the stack tracer itself. > > */ > > stack_dump_trace[0] = ip; > > max_stack_trace.nr_entries++; > > I think that "ip" here is the "return address for func" in your Ah, you are correct (for fentry). > ascii art, and it should be already in the list if a frame is made > by mcount (or func_call). > > In fact, stack tracer on arm64 works OK even without the patch[3/3] > if the code quoted above is commented out. > Even on x86, the code is conditional and not activated if the kernel > is compiled without -mfentry before the following commit: > commit 4df297129f62 ("tracing: Remove most or all of stack tracer stack size from stack_max_size") > > So what do I misunderstand here? > Hmm, I haven't touched the stack trace code in a while. With the added stack frame for fentry, the hacks there are probably not needed. I'll take a look at it and try to clean up the code. Thanks, -- Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: rostedt@goodmis.org (Steven Rostedt) Date: Wed, 15 Jul 2015 10:55:36 -0400 Subject: [RFC 2/3] arm64: refactor save_stack_trace() In-Reply-To: <55A646EE.6030402@linaro.org> References: <1436765375-7119-1-git-send-email-takahiro.akashi@linaro.org> <1436765375-7119-3-git-send-email-takahiro.akashi@linaro.org> <20150714093154.4d73e551@gandalf.local.home> <55A5A75A.1060401@linaro.org> <20150714225105.6c1e4f15@gandalf.local.home> <55A646EE.6030402@linaro.org> Message-ID: <20150715105536.42949ea9@gandalf.local.home> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Wed, 15 Jul 2015 20:41:34 +0900 AKASHI Takahiro wrote: > Thank you for the explanation. But what I don't really understand here > is why we need to add the "current function" to the stack dump list > returned by save_stack_trace(): > > In check_stack(), > > /* > > * Add the passed in ip from the function tracer. > > * Searching for this on the stack will skip over > > * most of the overhead from the stack tracer itself. > > */ > > stack_dump_trace[0] = ip; > > max_stack_trace.nr_entries++; > > I think that "ip" here is the "return address for func" in your Ah, you are correct (for fentry). > ascii art, and it should be already in the list if a frame is made > by mcount (or func_call). > > In fact, stack tracer on arm64 works OK even without the patch[3/3] > if the code quoted above is commented out. > Even on x86, the code is conditional and not activated if the kernel > is compiled without -mfentry before the following commit: > commit 4df297129f62 ("tracing: Remove most or all of stack tracer stack size from stack_max_size") > > So what do I misunderstand here? > Hmm, I haven't touched the stack trace code in a while. With the added stack frame for fentry, the hacks there are probably not needed. I'll take a look at it and try to clean up the code. Thanks, -- Steve