From patchwork Mon Jan 20 17:05:14 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jean Pihet X-Patchwork-Id: 3513751 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 584609F2D6 for ; Mon, 20 Jan 2014 17:05:49 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4BD372015A for ; Mon, 20 Jan 2014 17:05:48 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 24EF520142 for ; Mon, 20 Jan 2014 17:05:47 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1W5II9-0007rE-G0; Mon, 20 Jan 2014 17:05:41 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1W5II7-0006OQ-0D; Mon, 20 Jan 2014 17:05:39 +0000 Received: from mail-ve0-f177.google.com ([209.85.128.177]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1W5II5-0006NJ-1b for linux-arm-kernel@lists.infradead.org; Mon, 20 Jan 2014 17:05:37 +0000 Received: by mail-ve0-f177.google.com with SMTP id jz11so974059veb.8 for ; Mon, 20 Jan 2014 09:05:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8KqZU1yCFLNZBE8DTSNj8P+o2s/HBQfSVA7FV3XVT8M=; b=kkMiGTQzXZMH9ZyNGsib7NskluLnMbvD+SPnBHj/683DML3Bak6/eyb6BOFQgdkuPn /2h5UV4tyx9g9yKqAgoyW+LK4sYAV11ibtn/maYFQBUWKpFBTyZzoy4Jg2tgffvagGW/ h/MY5XDmFdUzVaCICdn3JFbMklH4lF95NdyMySO+0p5cEcj3M0AcHUv/gnZ679kvbh7r mIwRMV81lOQfIa/GonFwhGjgLvQd8mPUV0SAnxNahgnRGgxYPsaZkEGm+ul6ND+v2o1r qylLwUOP+ef7Jofud9Cp+UaIVNJtyAoeK8PT0VLl4g+qbyBaXxzQ9s1wU+3MFr5uJDoD nESw== X-Gm-Message-State: ALoCoQnEw7u6eahtJWUXq3/P8BEG3Sg7LRICn4WCv/hmxnFaB7Br+iz2FhG5tlUZmGkhe1wL9xXJ MIME-Version: 1.0 X-Received: by 10.58.248.198 with SMTP id yo6mr3184vec.40.1390237514555; Mon, 20 Jan 2014 09:05:14 -0800 (PST) Received: by 10.58.100.79 with HTTP; Mon, 20 Jan 2014 09:05:14 -0800 (PST) In-Reply-To: <20140117100723.GB16003@mudshark.cambridge.arm.com> References: <1389869123-5884-1-git-send-email-jean.pihet@linaro.org> <20140116115634.GE30257@mudshark.cambridge.arm.com> <20140116125727.GI30257@mudshark.cambridge.arm.com> <20140117100723.GB16003@mudshark.cambridge.arm.com> Date: Mon, 20 Jan 2014 18:05:14 +0100 Message-ID: Subject: Re: [PATCH] ARM64: perf: support dwarf unwinding in compat mode From: Jean Pihet To: Will Deacon X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140120_120537_117940_5D8F2D9B X-CRM114-Status: GOOD ( 14.58 ) X-Spam-Score: -2.6 (--) Cc: "linaro-kernel@lists.linaro.org" , Steve Capper , "patches@linaro.org" , "linux-kernel@vger.kernel.org" , Arnaldo , Jiri Olsa , Ingo Molnar , "linux-arm-kernel@lists.infradead.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Hi Will, Here is an updated version of the change, which uses compat_sp at only one place. The drawback is that compat_user_mode is checked when calling compat_user_stack_pointer, which seems unnecessary. Unfortunately the check is not optimized out by the complier as I could check with objdump -S. What do you think? Regards, Jean On 17 January 2014 11:07, Will Deacon wrote: > On Fri, Jan 17, 2014 at 09:00:09AM +0000, Jean Pihet wrote: >> On 16 January 2014 14:47, Jean Pihet wrote: >> >> So the simplest thing would be to make compat_user_stack_pointer expand to >> >> user_stack_pointer(current_pt_regs()) on arm64 and merge that in with your >> >> original patch fixing user_stack_pointer. >> >> I see 2 issues in your proposal: >> >> 1) user_stack_pointer(regs) calls compat_user_stack_pointer if >> compat_user_mode(regs)) and compat_user_stack_pointer expands to >> user_stack_pointer. I see a circular dependency in the macros. > > Not today it doesn't, so you just need to avoid writing the circular > dependency and instead make user_stack_pointer access (regs)->compat_sp > instead. > >> 2) current_pt_regs() returns the current task regs although perf >> passes a regs struct that had been recorded previously. > > Yes, but compat_user_stack_pointer doesn't take a regs paramater anyway, so > there's no change in behaviour here. > > Will diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h index fda2704..e71f81f 100644 --- a/arch/arm64/include/asm/compat.h +++ b/arch/arm64/include/asm/compat.h @@ -228,7 +228,7 @@ static inline compat_uptr_t ptr_to_compat(void __user *uptr) return (u32)(unsigned long)uptr; } -#define compat_user_stack_pointer() (current_pt_regs()->compat_sp) +#define compat_user_stack_pointer() (user_stack_pointer(current_pt_regs())) static inline void __user *arch_compat_alloc_user_space(long len) { diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h index fbb0020..86d5b54 100644 --- a/arch/arm64/include/asm/ptrace.h +++ b/arch/arm64/include/asm/ptrace.h @@ -133,7 +133,7 @@ struct pt_regs { (!((regs)->pstate & PSR_F_BIT)) #define user_stack_pointer(regs) \ - ((regs)->sp) + (!compat_user_mode(regs)) ? ((regs)->sp) : ((regs)->compat_sp) /* * Are the current registers suitable for user mode? (used to maintain