From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17467 invoked by alias); 1 Feb 2006 13:02:12 -0000 Received: (qmail 17460 invoked by uid 22791); 1 Feb 2006 13:02:11 -0000 X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org Received: from mail8.hitachi.co.jp (HELO mail8.hitachi.co.jp) (133.145.228.43) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 01 Feb 2006 13:02:06 +0000 Received: from mlsv10.hitachi.co.jp by mail8.hitachi.co.jp (8.9.3p3/3.7W-mail8) id WAA25894; Wed, 1 Feb 2006 22:02:03 +0900 Received: from mfilter-s1.hitachi.co.jp by mlsv10.hitachi.co.jp (8.12.11/8.12.11) id k11D22fh015363; Wed, 1 Feb 2006 22:02:02 +0900 Received: from vshuts1.hitachi.co.jp (unverified) by mfilter-s1.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with SMTP id ; Wed, 1 Feb 2006 22:01:57 +0900 Received: from hsdlgw92.sdl.hitachi.co.jp ([133.144.7.20]) by vshuts1.hitachi.co.jp with SMTP id M2006020122015613226 ; Wed, 01 Feb 2006 22:01:56 +0900 Received: from vgate2.sdl.hitachi.co.jp by hsdlgw92.sdl.hitachi.co.jp (8.9.3/3.7W01100113) id WAA22676; Wed, 1 Feb 2006 22:01:56 +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 M2006020122015521404 ; Wed, 01 Feb 2006 22:01:55 +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 k11D1tnO009477; Wed, 1 Feb 2006 22:01:55 +0900 Message-ID: <43E0B165.2020405@sdl.hitachi.co.jp> Date: Wed, 01 Feb 2006 13:02:00 -0000 From: Masami Hiramatsu User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: ja, en-us, en 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][2/2] kprobe: kprobe-booster against 2.6.16-rc1 for i386 References: <43DE0A4D.20908@sdl.hitachi.co.jp> <43DEB290.1050000@sdl.hitachi.co.jp> <20060131145053.235e27e4.akpm@osdl.org> In-Reply-To: <20060131145053.235e27e4.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/msg00341.txt.bz2 Hi, Andrew Andrew Morton wrote: > These preempt tricks look rather nasty. Can you please describe what the > problem is, precisely? And how this code avoids it? Perhaps we can find > something cleaner. The problem is how to remove the copied instructions of the kprobe *safely* on the preemptable kernel (CONFIG_PREEMPT=y). Kprobes basically executes the following actions; (1)int3 (2)preempt_disable() (3)kprobe_prehandler() (4)copied instructioin(single step) (5)kprobe_posthandler() (6)preempt_enable() (7)return to the original code During the execution of copied instruction, preemption is disabled (from step (2) to (6)). When unregistering the probes, Kprobe waits for RCU quiescent state by using synchronize_sched() after removing int3 instruction. Thus we can ensure the copied instruction is not executed. On the other hand, kprobe-booster executes the following actions; (1)int3 (2)preempt_disable() (3)kprobe_prehandler() (4)preempt_enable() <-- this one is added by my patch (5)copied instruction(direct execution) (6)jmp back to the original code The problem is that we have no way to prevent preemption on step (5) or (6). We cannot call preempt_disable() after step (6), because there are no rooms to do that. Thus, some other processes may be preempted at step(5) or (6) on preemptable kernel. And I couldn't find the easy way to ensure that other processes' stack do *not* have the address of them. (I thought some way to do that, but those are very costly.) So currently, I simply boost the kprobe only when the probe point is already preemption disabled. > Also, the patch adds a preempt_enable() but I don't see a corresponding > preempt_disable(). Am I missing something? It is corresponding to the preempt_disable() in the top of kprobe_handler(). I copied the code of kprobe_handler() here: static int __kprobes kprobe_handler(struct pt_regs *regs) { struct kprobe *p; int ret = 0; kprobe_opcode_t *addr = NULL; unsigned long *lp; struct kprobe_ctlblk *kcb; /* * We don't want to be preempted for the entire * duration of kprobe processing */ preempt_disable(); <-- HERE kcb = get_kprobe_ctlblk(); Best regards, -- Masami HIRAMATSU 2nd Research Dept. Hitachi, Ltd., Systems Development Laboratory E-mail: hiramatu@sdl.hitachi.co.jp