This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: [RFC] Design + prototype: Multiple handler sets per probe address
On Mon, Apr 04, 2005 at 08:05:37AM -0400, Ananth N Mavinakayanahalli wrote:
> William Cohen wrote:
> >Ananth N Mavinakayanahalli wrote:
> >
> >>William Cohen wrote:
> >
> >...
> >
> >>>
> >>>I appologize for the verbose output. I have also attached output of
> >>>the test results. There are some warning about allocating sleeping
> >>>function.
> >>
> >>
> >>
> >>The warning appears only in one of the eight runs. Will investigate
> >>this. A GFP_KERNEL/GFP_ATOMIC issue, probably - but if so, why only in
> >>one of the eight runs? Beats me!
> >
> >
> >I suspect that is the first time that kprobes needs to really allocate
> >memory. The remaining kprobes can uses that access from iteration 1 of
> >the loop.
>
> The third unregister_kprobe() call will kfree() the aggr_kp in each
> iteration.
>
> >...
> >
> >>>It seems like it would be useful to have unregister_kprobe() return
> >>>whether the operation was successful or not. Be able to catch cases
> >>>were code attempts to remove a probe twice.
> >>
> >>
> >>
> >>Changing the existing interface :-) But I suppose users who don't care
> >>about the return code may as well ignore it.
> >
> >
> >It was a thought. Trying to make the code be better able to determine
> >when something has gone wrong.
> >
>
> In fact, Suparna suggested an alternate design approach to the multiple
> handlers issue. I will try and work on that design too - Suparna's
> method has the advantage that we may not have to modify the arch
> specific kprobe code at all.
Cool - look forward to it.
Multiple handlers for jprobes case seems a little tricky, but
maybe you'll come up with good ideas.
Regards
Suparna
>
> Thanks,
> Ananth
--
Suparna Bhattacharya (suparna@in.ibm.com)
Linux Technology Center
IBM Software Lab, India