Experiences with cvs runtime

[Ananth N Mavinakayanahalli]

On Wed, Apr 27, 2005 at 01:48:07PM -0700, Martin Hunt wrote:
> On Wed, 2005-04-27 at 15:45 -0400, Ananth N Mavinakayanahalli wrote:
> > Hi,
> > 
> > I was trying to use the probes in the runtime cvs to see if they can be
> > used to test the kprobes scalability patch prototype. I ran into a few
> > problems when trying to use kprobe_where_func.c.
> > 
> > This test was carried out on a system that was running a preempt enabled
> > smp kernel (though the machine itself was uni processor). Digging around
> > a bit, I see that:
> > 
> > - many runtime (and one relayfs) files use smp_processor_id() without
> > disabling preemption
> 
> Which caused a problem when you used printk() within a probe, I assume.
> We should probably disable preemption during all probes. Unless the
> script compiler can guarantee that scripts won't call something that
> tries to reschedule during a probe.

Kprobe infrastructure ensures that (un)registration and all handlers run 
with preemption disabled. The problem here is seen during pre and post 
processing by the runtime. 

> > - the stp script assumes that relayfs is built in as a kernel module,
> > while it can be configured tristate (<*>, <M>, <>).
> 
> Do you have a suggested fix for that?  Offhand I can't think how to test
> if relayfs is in a kernel from a script. "grep relayfs /proc/kallsyms"
> works but is /proc/kallsyms always present now? 

AFAICS, CONFIG_KALLSYMS=y in most defconfigs. Another crude method would
be to see if the System.map has any of the relayfs API entries in it
before loading the module.

Thanks,
Ananth