Re: [PATCH] module interface improvement for kprobes

[Frank Ch. Eigler]

Christoph Hellwig <hch@xxxxxxxxxxxxx> writes:

> [...]
> > Why shouldn't I put a probe into a module other than at a symbol I can
> > find with kallsyms?  For example, I'm interested when a particular
> > module hits an error condition that occurs.  [...]
>
> How do you find that offset?  

The same way one would find an address now: by a mixture of
online/offline processing of symbol tables, debugging data, and/or
disassembly.

> You'll probably mention the S-Word but we really want something that
> works with the latest kernel, not just the vendor trees.

Why are you under the impression that systemtap doesn't work with any
particular "latest kernel"?

> [...] Adding another field to struct kprobe to specify an offset
> into the symbol would be the logical extension of that.

At the top you ask rhetorically about how an offset would be found (as
if it were difficult) ...  and here you assert that it is a logical
extension to put it into the API?  I'm confused - which is it?

> > Your example works for a very small number of symbols, but with a large
> > number it could take a long time to register the kprobes.  [...]
> Registering a kprobe is everything but a fastpath, and you definitly
> should not have a lot of probes anyway.  [...]

It is not difficult to imagine situations where one wants to have
hundreds or thousands of active probes: one is function entry/exit
tracing; another is assertion checking.  (If only there was a system
for conveniently expressing these ... oh never mind.)

The idea behind module_get_byname() was to avoid changes in kprobes
etc., and keeping in mind that the same sort of module-name lookup is
already available to userspace via sysfs.  If folks insist that
instead, kprobes be extended to do this step of the probe address
calculations internally, I guess we could use that too.  It would have
to punt if !CONFIG_KALLSYMS, which is too bad, since systemtap and
kprobes work fine without kallsyms now.

- FChE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/