2009-01-13 01:55:31

by Masami Hiramatsu

[permalink] [raw]
Subject: [RFC][PATCH -mm 0/6] kprobes: Per-probe disabling support

Hi,

Currently, kprobes can disable all probes at once, but can't disable it
individually (not unregister, just disable an kprobe, because unregistering
needs to wait for scheduler synchronization).
These patches introduce APIs for on-the-fly per-probe disabling and
re-enabling by dis-arming/re-arming its breakpoint instruction.

These patches can be applied on the latest -mm tree including my previous
bugfix patch (http://lkml.org/lkml/2009/1/5/472).

You can download a test of this feature from here:
http://sources.redhat.com/bugzilla/attachment.cgi?id=3082&action=view

Thank you,

Documentation/kprobes.txt | 38 +++++-
include/linux/kprobes.h | 51 +++++++-
kernel/kprobes.c | 281 ++++++++++++++++++++++++++++++++--------------
3 files changed, 279 insertions(+), 91 deletions(-)


--
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: [email protected]





Subject: Re: [RFC][PATCH -mm 0/6] kprobes: Per-probe disabling support

On Mon, Jan 12, 2009 at 08:55:27PM -0500, Masami Hiramatsu wrote:
> Hi,
>
> Currently, kprobes can disable all probes at once, but can't disable it
> individually (not unregister, just disable an kprobe, because unregistering
> needs to wait for scheduler synchronization).
> These patches introduce APIs for on-the-fly per-probe disabling and
> re-enabling by dis-arming/re-arming its breakpoint instruction.
>
> These patches can be applied on the latest -mm tree including my previous
> bugfix patch (http://lkml.org/lkml/2009/1/5/472).
>
> You can download a test of this feature from here:
> http://sources.redhat.com/bugzilla/attachment.cgi?id=3082&action=view
>
> Thank you,
>
> Documentation/kprobes.txt | 38 +++++-
> include/linux/kprobes.h | 51 +++++++-
> kernel/kprobes.c | 281 ++++++++++++++++++++++++++++++++--------------
> 3 files changed, 279 insertions(+), 91 deletions(-)

Acked-by: Ananth N Mavinakayanahalli <[email protected]>

...for the patchset.

Thanks for the work Masami. We'll need to allow this set to cook in
-mm/next for a few weeks before it goes upstream.

Ananth