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: "Frank Ch. Eigler" <fche at redhat dot com>
- To: "Stone, Joshua I" <joshua dot i dot stone at intel dot com>
- Cc: "Keshavamurthy, Anil S" <anil dot s dot keshavamurthy 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>, "Frank Ch. Eigler" <fche at redhat dot com>, hch at infradead dot org
- Date: Fri, 23 Mar 2007 14:22:48 -0400
- Subject: Re: [RFC][Patch 1/4] kprobe fast unregistration
- References: <20070323180527.GA13728@bambi.jf.intel.com> <16D5B9AB904B0B46B22A27002EE3A8C82793BB@scsmsx415.amr.corp.intel.com>
Hi -
Keshavamurthy, Anil S wrote:
> I agree with Christoph that the interface is horrible and error prone.
Really? What possible problems can occur? The worst that occurs to
me is that if someone forgets to call the commit function, the kprobes
will still be disabled, but memory won't be recycled for a while. Is
this really so bad, considering that a kprobe_unregister is to imply a
commit? Maybe if kprobe_register can also implied a commit, we can
bound the conceivable memory leak.
Would it be possible to allay even that concern with an automated
deferred/periodic commit?
- FChE