From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14361 invoked by alias); 28 Feb 2006 06:07:30 -0000 Received: (qmail 14213 invoked by uid 22791); 28 Feb 2006 06:07:29 -0000 X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org Received: from mail7.hitachi.co.jp (HELO mail7.hitachi.co.jp) (133.145.228.42) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 28 Feb 2006 06:07:25 +0000 Received: from mlsv9.hitachi.co.jp by mail7.hitachi.co.jp (8.9.3p3/3.7W-mail7) id PAA28163; Tue, 28 Feb 2006 15:07:23 +0900 Received: from mfilter-s6.hitachi.co.jp by mlsv9.hitachi.co.jp (8.12.11/8.12.11) id k1S67MPA008823; Tue, 28 Feb 2006 15:07:22 +0900 Received: from vshuts5.hitachi.co.jp (unverified) by mfilter-s6.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with SMTP id ; Tue, 28 Feb 2006 15:07:21 +0900 Received: from hsdlgw92.sdl.hitachi.co.jp ([133.144.7.20]) by vshuts5.hitachi.co.jp with SMTP id M2006022815072102227 ; Tue, 28 Feb 2006 15:07:21 +0900 Received: from vgate2.sdl.hitachi.co.jp by hsdlgw92.sdl.hitachi.co.jp (8.9.3/3.7W01100113) id PAA08623; Tue, 28 Feb 2006 15:07:21 +0900 Received: from maila.sdl.hitachi.co.jp ([133.144.14.196]) by vgate2.sdl.hitachi.co.jp (SAVSMTP 3.1.1.32) with SMTP id M2006022815072022074 ; Tue, 28 Feb 2006 15:07:20 +0900 Received: from [192.168.16.226] ([192.168.16.226]) by maila.sdl.hitachi.co.jp (8.13.1/3.7W04031011) with ESMTP id k1S67KRF018784; Tue, 28 Feb 2006 15:07:20 +0900 Message-ID: <4403E894.4050300@sdl.hitachi.co.jp> Date: Tue, 28 Feb 2006 06:07:00 -0000 From: Masami Hiramatsu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Morton CC: ananth@in.ibm.com, prasanna@in.ibm.com, anil.s.keshavamurthy@intel.com, systemtap@sources.redhat.com, jkenisto@us.ibm.com, linux-kernel@vger.kernel.org, sugita@sdl.hitachi.co.jp, soshima@redhat.com, haoki@redhat.com Subject: Re: [PATCH][take2][2/2] kprobe: kprobe-booster against 2.6.16-rc5 for i386 References: <43DE0A4D.20908@sdl.hitachi.co.jp> <4402E920.5080402@sdl.hitachi.co.jp> <20060227185012.037c8830.akpm@osdl.org> In-Reply-To: <20060227185012.037c8830.akpm@osdl.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q1/txt/msg00656.txt.bz2 Hi, Andrew Andrew Morton wrote: > Masami Hiramatsu wrote: >> Here is a patch of kprobe-booster for i386 arch against linux-2.6.16-rc5. >> The kprobe-booster patch is also under the influence of the NX-protection >> support patch. So, I fixed that. >> >> Could you replace the previous patches with these patches? > > I'd prefer not to. Once a patch has been in -mm for this long I really > prefer to not see wholesale replacements. When people do this to me I > usually turn their replacements into incremental patches so we can see what > changed. Which is useful. > > Your first patch was identical to what I already have, so I dropped that. Thank you for your advice. I will re-create an additional patch against recent -mm tree. > Your second patch made these changes: > > --- devel/arch/i386/kernel/kprobes.c~kprobe-kprobe-booster-against-2616-rc5-for 2006-02-27 18:40:29.000000000 -0800 > +++ devel-akpm/arch/i386/kernel/kprobes.c 2006-02-27 18:40:57.000000000 -0800 > @@ -305,7 +305,7 @@ static int __kprobes kprobe_handler(stru > > if (p->ainsn.boostable == 1 && > #ifdef CONFIG_PREEMPT > - !(pre_preempt_count) && /* > + !(pre_preempt_count()) && /* > * This enables booster when the direct > * execution path aren't preempted. > */ > @@ -313,7 +313,7 @@ static int __kprobes kprobe_handler(stru > !p->post_handler && !p->break_handler ) { > /* Boost up -- we can execute copied instructions directly */ > reset_current_kprobe(); > - regs->eip = (unsigned long)&p->ainsn.insn; > + regs->eip = (unsigned long)p->ainsn.insn; > preempt_enable_no_resched(); > return 1; > } > > The first hunk is surely wrong - pre_preempt_count is a local unsigned > integer, not a function. I'm sorry. It's my fault. The first hunk is just a degradation. > And I'm not sure about the second hunk either - surely an `eip' should > point at an instruction, not be assigned the value of an instruction? This change is important. Because NX-protection support patch makes the ainsn.insn a pointer instead of a data structure, so now (&p->ainsn.insn) means just an address of the pointer -- not the instruction address. > So I'll drop both patches. If you have bugfixes, please make them relative > to already-merged things. Against most-recent -mm is best, as I do fix > patches up, and other people send fixes which you might not have merged > locally. And please ensure that the changes compile and run with and > without CONFIG_PREEMPT! OK. I will get the latest -mm tree and test it. And I will re-send the patch ASAP. -- Masami HIRAMATSU 2nd Research Dept. Hitachi, Ltd., Systems Development Laboratory E-mail: hiramatu@sdl.hitachi.co.jp