From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [63.240.77.84]) by ozlabs.org (Postfix) with ESMTP id DD62BDDE9A for ; Tue, 25 Sep 2007 10:59:47 +1000 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Roland McGrath To: Benjamin Herrenschmidt Subject: Re: [PATCH 1/2] powerpc: ptrace CHECK_FULL_REGS In-Reply-To: Benjamin Herrenschmidt's message of Tuesday, 25 September 2007 10:33:26 +1000 <1190680406.12382.9.camel@localhost.localdomain> References: <20070924235052.5AFC24D04B7@magilla.localdomain> <1190680406.12382.9.camel@localhost.localdomain> Message-Id: <20070925005945.02E924D04B7@magilla.localdomain> Date: Mon, 24 Sep 2007 17:59:44 -0700 (PDT) Cc: David Woodhouse , linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org, Paul Mackerras , Andrew Morton , Linus Torvalds List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > Yup, I think I ditched most of them.. for some reason I decided it > couldn't happen, but maybe I'm wrong ? Well, it's a BUG_ON. It's supposed to be for something that "can't happen". That's why it's a sanity check, not a wild assertion. ;-) The 2/2 patch is an example of a bug that CHECK_FULL_REGS catches. In the status quo, using PTRACE_PEEKUSR in a bug case crashes while using PTRACE_GETREGS in the same place might get bogus data. (In the actual bug thus found, the data is not bogus and only the bit that FULL_REGS checks is.) Thanks, Roland