This is the mail archive of the mailing list for the systemtap project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC][Patch 1/4] kprobe fast unregistration

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]