Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752459AbbHQGHJ (ORCPT ); Mon, 17 Aug 2015 02:07:09 -0400 Received: from mail-pa0-f52.google.com ([209.85.220.52]:36079 "EHLO mail-pa0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750803AbbHQGHH (ORCPT ); Mon, 17 Aug 2015 02:07:07 -0400 Message-ID: <55D17A04.7020800@linaro.org> Date: Mon, 17 Aug 2015 15:07:00 +0900 From: AKASHI Takahiro User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Will Deacon CC: Catalin Marinas , "rostedt@goodmis.org" , "jungseoklee85@gmail.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 v2 1/4] ftrace: allow arch-specific check_stack() References: <1438674249-3447-1-git-send-email-takahiro.akashi@linaro.org> <1438674249-3447-2-git-send-email-takahiro.akashi@linaro.org> <20150811170321.GB29880@arm.com> In-Reply-To: <20150811170321.GB29880@arm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2012 Lines: 44 Will, On 08/12/2015 02:03 AM, Will Deacon wrote: > On Tue, Aug 04, 2015 at 08:44:06AM +0100, AKASHI Takahiro wrote: >> A stack frame pointer may be used in a different way depending on >> cpu architecture. Thus it is not always appropriate to slurp the stack >> contents, as currently done in check_stack(), in order to calcurate >> a stack index (height) at a given function call. At least not on arm64. >> >> This patch extract potentially arch-specific code from check_stack() >> and puts it into a new arch_check_stack(), which is declared as weak. >> So we will be able to add arch-specific and most efficient way of >> stack traversing Later. >> >> Signed-off-by: AKASHI Takahiro > > If arm64 is the only architecture behaving differently, then I'm happy > to reconsider the fix to unwind_frame that we merged in e306dfd06fcb > ("ARM64: unwind: Fix PC calculation"). I'd have thought any architecture > with a branch-and-link instruction would potentially have the same issue, > so we could just be fixing things in the wrong place if ftrace works > everywhere else. I'm not the right person to answer for other architectures (and ftrace behavior on them.) The only thing I know is that current ftrace stack tracer works correctly only if the addresses stored and found on stack match to the ones returned by save_stack_trace(). Anyway, the fix above is not the only reason that I want to introduce arch-specific arch_check_stack(). Other issues to fix include - combined case of stack tracer and function graph tracer (common across arch's) - exception entries (as I'm trying to address in RFC 4/4) - in-accurate stack size (for each function, my current fix is not perfect though.) Thanks, -Takahiro AKASHI > Will > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/