From patchwork Wed Apr 14 01:59:31 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Miller X-Patchwork-Id: 50092 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id AF6E4B7D12 for ; Wed, 14 Apr 2010 11:59:28 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754394Ab0DNB71 (ORCPT ); Tue, 13 Apr 2010 21:59:27 -0400 Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:49035 "EHLO sunset.davemloft.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754372Ab0DNB71 (ORCPT ); Tue, 13 Apr 2010 21:59:27 -0400 Received: from localhost (localhost [127.0.0.1]) by sunset.davemloft.net (Postfix) with ESMTP id 5BE3824C08F; Tue, 13 Apr 2010 18:59:31 -0700 (PDT) Date: Tue, 13 Apr 2010 18:59:31 -0700 (PDT) Message-Id: <20100413.185931.244224837.davem@davemloft.net> To: fweisbec@gmail.com Cc: rostedt@goodmis.org, sparclinux@vger.kernel.org Subject: Re: [PATCH 7/7] sparc64: Add function graph tracer support. From: David Miller In-Reply-To: <20100413.165639.257883930.davem@davemloft.net> References: <20100413.145638.122252984.davem@davemloft.net> <20100413220542.GG5602@nowhere> <20100413.165639.257883930.davem@davemloft.net> X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Sender: sparclinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: sparclinux@vger.kernel.org From: David Miller Date: Tue, 13 Apr 2010 16:56:39 -0700 (PDT) > I'll dig further. Ok Frederic, I think I figured it out. We only save 128 bytes of stack space in the mcount stubs, but that's not enough. 128 bytes is enough for the register window, but any function we call is allowed to save the first six incoming arguments to pre-assigned stack frame slots. That means we have to allocate, at a minimum, 176 bytes of stack space if we call any C functions. (176 == 128 + (8 * 6)) These arg save stores only happen in functions where there is a bit of register pressure, that's why we only sometimes see this. The net result is that when we hit this, the parent's stack frame gets writtenw ith garbage. And that's why the crashes look so random. I'll commit this to sparc-2.6 and push it out to Linus. I'm beating up a machine pretty hard with various tracers enabled and I haven't see any suspicious symptoms yet :-) -------------------- sparc64: Allocate sufficient stack space in ftrace stubs. 128 bytes is sufficient for the register window save area, but the calling conventions allow the callee to save up to 6 incoming argument registers into the stack frame after the register window save area. This means a minimal stack frame is 176 bytes (128 + (6 * 8)). This fixes random crashes when using the function tracer. Reported-by: Frederic Weisbecker Signed-off-by: David S. Miller --- arch/sparc/lib/mcount.S | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/sparc/lib/mcount.S b/arch/sparc/lib/mcount.S index 3753e3c..3ad6cbd 100644 --- a/arch/sparc/lib/mcount.S +++ b/arch/sparc/lib/mcount.S @@ -34,7 +34,7 @@ mcount: cmp %g1, %g2 be,pn %icc, 1f mov %i7, %g3 - save %sp, -128, %sp + save %sp, -176, %sp mov %g3, %o1 jmpl %g1, %o7 mov %i7, %o0 @@ -56,7 +56,7 @@ mcount: nop 5: mov %i7, %g2 mov %fp, %g3 - save %sp, -128, %sp + save %sp, -176, %sp mov %g2, %l0 ba,pt %xcc, ftrace_graph_caller mov %g3, %l1 @@ -85,7 +85,7 @@ ftrace_caller: lduw [%g1 + %lo(function_trace_stop)], %g1 brnz,pn %g1, ftrace_stub mov %fp, %g3 - save %sp, -128, %sp + save %sp, -176, %sp mov %g2, %o1 mov %g2, %l0 mov %g3, %l1 @@ -120,7 +120,7 @@ ENTRY(ftrace_graph_caller) END(ftrace_graph_caller) ENTRY(return_to_handler) - save %sp, -128, %sp + save %sp, -176, %sp call ftrace_return_to_handler mov %fp, %o0 jmpl %o0 + 8, %g0