This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH -tip v5 03/10] kprobes: Introduce kprobes jump optimization
- From: Frederic Weisbecker <fweisbec at gmail dot com>
- To: Masami Hiramatsu <mhiramat at redhat dot com>
- Cc: Ingo Molnar <mingo at elte dot hu>, Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, lkml <linux-kernel at vger dot kernel dot org>, systemtap <systemtap at sources dot redhat dot com>, DLE <dle-develop at lists dot sourceforge dot net>, Jim Keniston <jkenisto at us dot ibm dot com>, Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>, Christoph Hellwig <hch at infradead dot org>, Steven Rostedt <rostedt at goodmis dot org>, "H. Peter Anvin" <hpa at zytor dot com>, Anders Kaseorg <andersk at ksplice dot com>, Tim Abbott <tabbott at ksplice dot com>, Andi Kleen <andi at firstfloor dot org>, Jason Baron <jbaron at redhat dot com>, Mathieu Desnoyers <mathieu dot desnoyers at polymtl dot ca>
- Date: Tue, 24 Nov 2009 04:31:37 +0100
- Subject: Re: [PATCH -tip v5 03/10] kprobes: Introduce kprobes jump optimization
- 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>
On Tue, Nov 24, 2009 at 03:44:19AM +0100, Frederic Weisbecker wrote:
> On Mon, Nov 23, 2009 at 06:21:41PM -0500, Masami Hiramatsu wrote:
> > +static void kprobe_optimizer(struct work_struct *work);
> > +static DECLARE_DELAYED_WORK(optimizing_work, kprobe_optimizer);
> > +#define OPTIMIZE_DELAY 5
> > +
> > +/* Kprobe jump optimizer */
> > +static __kprobes void kprobe_optimizer(struct work_struct *work)
> > +{
> > + struct optimized_kprobe *op, *tmp;
> > +
> > + /* Lock modules while optimizing kprobes */
> > + mutex_lock(&module_mutex);
> > + mutex_lock(&kprobe_mutex);
> > + if (kprobes_all_disarmed)
> > + goto end;
> > +
> > + /* Wait quiesence period for ensuring all interrupts are done */
> > + synchronize_sched();
>
>
>
> It's not clear to me why you are doing that.
> Is this waiting for pending int 3 kprobes handlers
> to complete? If so, why, and what does that prevent?
I _might_ have understood.
You have set up the optimized flags, then you wait for
any old-style int 3 kprobes to complete and route
to detour buffer so that you can patch the jump
safely in the dead code? (and finish with first byte
by patching the int 3 itself)