From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31362 invoked by alias); 24 Nov 2009 03:15:11 -0000 Received: (qmail 31343 invoked by uid 22791); 24 Nov 2009 03:15:09 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-ew0-f213.google.com (HELO mail-ew0-f213.google.com) (209.85.219.213) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Nov 2009 03:15:02 +0000 Received: by ewy5 with SMTP id 5so3027205ewy.10 for ; Mon, 23 Nov 2009 19:15:00 -0800 (PST) Received: by 10.213.110.4 with SMTP id l4mr4488540ebp.81.1259032499727; Mon, 23 Nov 2009 19:14:59 -0800 (PST) Received: from nowhere (ADijon-552-1-123-3.w92-148.abo.wanadoo.fr [92.148.186.3]) by mx.google.com with ESMTPS id 7sm1949167eyg.33.2009.11.23.19.14.57 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Nov 2009 19:14:59 -0800 (PST) Received: by nowhere (nbSMTP-1.00) for uid 1000 (using TLSv1/SSLv3 with cipher RC4-MD5 (128/128 bits)) fweisbec@gmail.com; Tue, 24 Nov 2009 04:14:59 +0100 (CET) Date: Tue, 24 Nov 2009 03:15:00 -0000 From: Frederic Weisbecker To: Masami Hiramatsu Cc: Ingo Molnar , Ananth N Mavinakayanahalli , lkml , systemtap , DLE , Jim Keniston , Srikar Dronamraju , Christoph Hellwig , Steven Rostedt , "H. Peter Anvin" , Anders Kaseorg , Tim Abbott , Andi Kleen , Jason Baron , Mathieu Desnoyers Subject: Re: [PATCH -tip v5 07/10] kprobes/x86: Support kprobes jump optimization on x86 Message-ID: <20091124031456.GC6752@nowhere> References: <20091123232115.22071.71558.stgit@dhcp-100-2-132.bos.redhat.com> <20091123232211.22071.58974.stgit@dhcp-100-2-132.bos.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091123232211.22071.58974.stgit@dhcp-100-2-132.bos.redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q4/txt/msg00654.txt.bz2 On Mon, Nov 23, 2009 at 06:22:11PM -0500, Masami Hiramatsu wrote: > Introduce x86 arch-specific optimization code, which supports both of > x86-32 and x86-64. > > This code also supports safety checking, which decodes whole of a function > in which probe is inserted, and checks following conditions before > optimization: > - The optimized instructions which will be replaced by a jump instruction > don't straddle the function boundary. > - There is no indirect jump instruction, because it will jumps into > the address range which is replaced by jump operand. > - There is no jump/loop instruction which jumps into the address range > which is replaced by jump operand. > - Don't optimize kprobes if it is in functions into which fixup code will > jumps. > > This uses stop_machine() for corss modifying code from int3 to jump. > It doesn't allow us to modify code on NMI/SMI path. However, since > kprobes itself doesn't support NMI/SMI code probing, it's not a > problem. > > Changes in v5: > - Introduce stop_machine-based jump replacing. I realize now that int 3 live patching doesn't need stop_machine(). But still, I don't understand the int 3 unecessary step. You first force int 3 patching, and later try to optimize with a jump, using stop_machine(). But why the int 3 is a necessary first step? I guess it was necessary first when you used it as a gate: - patch with int 3, go to handler, go to old instruction that was patched, jump to original code that folows instruction that was patched - set up detour buffer, execute handler (from int 3) then route to detour buffer, and original code that follows - the code to be patched with the jump is now a dead code, jump to it And now that you use stop_machine(), the complexity could be reduced to: - decide kprobe mode - if int 3, then do like usual - if jmp, then prepare detour buffer, and patch with the jump, without worrying about routing int 3 to the detour buffer to create a dead code area. It is now safe because of stop_machine() Of course it's possible I completely misunderstood the whole thing :)