From patchwork Wed Dec 17 05:41:00 2008 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Miller X-Patchwork-Id: 14427 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.176.167]) by ozlabs.org (Postfix) with ESMTP id 53BE6DDF47 for ; Wed, 17 Dec 2008 16:41:05 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751047AbYLQFk7 (ORCPT ); Wed, 17 Dec 2008 00:40:59 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751145AbYLQFk7 (ORCPT ); Wed, 17 Dec 2008 00:40:59 -0500 Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:38382 "EHLO sunset.davemloft.net" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1751047AbYLQFk7 (ORCPT ); Wed, 17 Dec 2008 00:40:59 -0500 Received: from localhost (localhost [127.0.0.1]) by sunset.davemloft.net (Postfix) with ESMTP id 083E1C8C17E; Tue, 16 Dec 2008 21:41:01 -0800 (PST) Date: Tue, 16 Dec 2008 21:41:00 -0800 (PST) Message-Id: <20081216.214100.07002773.davem@davemloft.net> To: chris.torek@windriver.com Cc: sparclinux@vger.kernel.org Subject: Re: random dumb (or maybe not) question about sparc64 From: David Miller In-Reply-To: <20081209.041215.133030666.davem@davemloft.net> References: <200812091146.mB9Bkqn02109@elf.torek.net> <20081209.041215.133030666.davem@davemloft.net> X-Mailer: Mew version 6.1 on Emacs 22.1 / Mule 5.0 (SAKAKI) 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, 09 Dec 2008 04:12:15 -0800 (PST) > From: Chris Torek > Date: Tue, 09 Dec 2008 04:46:52 -0700 > > > The ptrace code uses flushw_user() to push user windows ... good > > enough, except, a bunch of other code then also does > > synchronize_user_stack(), but ptrace does not. ... > Perhaps the best place would be in the arch_ptrace_stop() hook. > I believe IA64 uses this for the register backing store on that > cpu. It seems to be created exactly for the case we are discussing > here. :) > > What do you think? I guess Chris is not excited enough about this issue to reply :-) Anyways, here is the fix I'll probably push upstream. 32-bit sparc will need something similar and I'll implement that too. Thanks for the report: --- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/sparc/include/asm/ptrace_64.h b/arch/sparc/include/asm/ptrace_64.h index 84e969f..cd6fbfc 100644 --- a/arch/sparc/include/asm/ptrace_64.h +++ b/arch/sparc/include/asm/ptrace_64.h @@ -114,6 +114,7 @@ struct sparc_trapf { #ifdef __KERNEL__ #include +#include static inline int pt_regs_trap_type(struct pt_regs *regs) { @@ -130,6 +131,14 @@ static inline bool pt_regs_clear_syscall(struct pt_regs *regs) return (regs->tstate &= ~TSTATE_SYSCALL); } +#define arch_ptrace_stop_needed(exit_code, info) \ +({ flush_user_windows(); \ + get_thread_wsaved() != 0; \ +}) + +#define arch_ptrace_stop(exit_code, info) \ + synchronize_user_stack() + struct global_reg_snapshot { unsigned long tstate; unsigned long tpc;