This is the mail archive of the systemtap@sources.redhat.com 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: instrumenting vs. module loading


Frank Ch. Eigler wrote:
Hi -

On Fri, May 13, 2005 at 10:29:09AM -0400, William Cohen wrote:


[...]  Hmmm, instrumenting each inline function site? For the kernel
that is known.  What happens when a module is loaded that uses an
instrumented inline function?


The way the translator probe points are going to be specified, the
target software is identified clearly (a particular module, or the
whole kernel).  If a probe point is for a module, and it's not loaded
at probe startup time, the initialization should abort.  Let's not
support a wildcard syntax for kernel-module selection until the
implications are better analyzed.


Or unload for that matter?


I imagine the translator arranging to increment the use-count of
modules that it places instrumentation into, to prevent their
premature removal.  (How does raw kprobes deal with this case?)

Please correct me if my understanding is wrong: Are you speaking of a
case where a kprobe is placed in a module text and than the module is unloaded?


We will anyway not have any subsequent hits of such a kprobe. There is
currently no "scavenging" done for such kprobes and in any case, kprobes
core doesn't have the knowledge if the kp.addr is a module text address
or not.

I don't have much idea about in kernel details of module loading and
unloading, but I'd imagine we'll encounter "interesting" issues if a
different module is loaded in the same text range with such a stray
kprobe.

Ananth


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