From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15057 invoked by alias); 25 Nov 2009 21:09:01 -0000 Received: (qmail 15045 invoked by uid 22791); 25 Nov 2009 21:09:01 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from hrndva-omtalb.mail.rr.com (HELO hrndva-omtalb.mail.rr.com) (71.74.56.124) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Nov 2009 21:08:54 +0000 Received: from [192.168.23.10] (really [74.67.89.75]) by hrndva-omta01.mail.rr.com with ESMTP id <20091125210852853.HSRX4786@hrndva-omta01.mail.rr.com>; Wed, 25 Nov 2009 21:08:52 +0000 Subject: Re: [PATCH -tip v5 03/10] kprobes: Introduce kprobes jump optimization From: Steven Rostedt Reply-To: rostedt@goodmis.org To: Masami Hiramatsu Cc: Frederic Weisbecker , Ingo Molnar , Ananth N Mavinakayanahalli , lkml , systemtap , DLE , Jim Keniston , Srikar Dronamraju , Christoph Hellwig , "H. Peter Anvin" , Anders Kaseorg , Tim Abbott , Andi Kleen , Jason Baron , Mathieu Desnoyers In-Reply-To: <4B0C492D.1060602@redhat.com> References: <20091123232115.22071.71558.stgit@dhcp-100-2-132.bos.redhat.com> <20091123232141.22071.53317.stgit@dhcp-100-2-132.bos.redhat.com> <20091124024417.GA6752@nowhere> <20091124033135.GE6752@nowhere> <4B0BFCF8.4060905@redhat.com> <20091124201357.GB5071@nowhere> <4B0C492D.1060602@redhat.com> Content-Type: text/plain Date: Wed, 25 Nov 2009 21:09:00 -0000 Message-Id: <1259183331.21397.71.camel@gandalf.stny.rr.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00712.txt.bz2 On Tue, 2009-11-24 at 15:59 -0500, Masami Hiramatsu wrote: > > I see...so the non-preemptible kernel requirement looks > > hard to workaround :-s > > It's the next challenge I think :-) > Even though, kprobes itself still work on preemptive kernel, > so we don't lose any functionality. >From kstop_machine, we could search all tasks to see if any are about to resume in the modified location. If there is, we could either 1) insert a normal kprobe 2) modify the return address of the task to jump to some trampoline to finish the work and return to the code spot with a direct jump. #2 is kind of nasty but seems like a fun thing to implement ;-) -- Steve