This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC][Patch 1/4] kprobe fast unregistration
- From: "Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: "Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>, "Stone, Joshua I" <joshua dot i dot stone at intel dot com>, Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>, Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, Prasanna S Panchamukhi <prasanna at in dot ibm dot com>, linux-kernel <linux-kernel at vger dot kernel dot org>, SystemTAP <systemtap at sources dot redhat dot com>, Satoshi Oshima <soshima at redhat dot com>, Hideo Aoki <haoki at redhat dot com>, Yumiko Sugita <yumiko dot sugita dot yf at hitachi dot com>, hch at infradead dot org
- Date: Tue, 27 Mar 2007 12:45:00 -0700
- Subject: Re: [RFC][Patch 1/4] kprobe fast unregistration
- References: <20070323180527.GA13728@bambi.jf.intel.com> <16D5B9AB904B0B46B22A27002EE3A8C82793BB@scsmsx415.amr.corp.intel.com> <20070323182248.GA32364@redhat.com> <20070323190127.GA13974@bambi.jf.intel.com> <y0mmz20n3ds.fsf@ton.toronto.redhat.com>
- Reply-to: "Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>
On Sun, Mar 25, 2007 at 10:29:51PM -0400, Frank Ch. Eigler wrote:
> > Hence, my suggestion would be to call them as disable_kprobe()
> > (instead of unregister_kprobes_fast() which is confusing and error
> > prone) and also to provide an opposite function to reenable_kprobe()
> > and finally provide unregister_disabled_kprobes() which is
> > essentially the same as commit_kprobes().
>
> One problem with this idea is that if the unregister_fast()=disable()
> is to become reversible, then the renamed commit_kprobes() will no
> longer be indempotent. There can no longer be a single system-wide
> deferred-kprobe-cleanup list, since individual kprobes clients might
> want to reinstate their probes in the future.
True, worth investigating..
>
> > > Would it be possible to allay even that concern with an automated
> > > deferred/periodic commit?
> > >
> > I would recomand that users call unregister_disabled_kprobes() explictly.
>
> But this would solve both problems (memory leaks and outstanding
> reference counts on modules). In this variant,
> unregister_kprobes_fast could replace unregister_kprobes outright, and
> the (builtin deferred) commit function would need not be exported.
The only problem with deferred builtin commit funcion would be that
the module will have no way of knowing when is the right time to reuse
the kprobe data structure after calling unregister_kprobe(), hence exlict
call is always better.
-Anil