This is the mail archive of the systemtap@sourceware.org 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: [RFC]-Approaches to user space probes ->>> Kprobes and kretprobes


Hi -

> [...]
> >> [...] In other words we should not see rp->nmissed > 0, however it
> >> is okay to for rp->kp.nmissed > 0.
> >
> >While we may *prefer* not to see any nmissed > 0, how bad do you think
> >the consequences are if we do miss a few?  What are the odds?

> Humm.. You are not getting my point. The problem is many times I
> have seen the count of Kprobes_handler_called and count of
> Kretprobes_handler_called for the same function are different. [...]

OK, so you are suggesting that this problem has occurred frequently.

> So if a script assumes that setting some value in Kprobes handler and
> try'ing to unset the same in kretprobe handler might be wrong. [...]
> I am concerned that people might come up with such kind of scripts and
> get wrong results.

That is a problem, but at least those wrong results are not silent.
They will be marked by "missed probes" counts shown at stap shutdown.

> What is the default "maxactive" value set by the systemtap for the
> return probes?

Zero, leaving it to kprobes to set its default.  If someone had a
better number to override the resulting value (NR_CPUS?), like a
couple of hundred, they can check in the one-line change to make it
happen.

- FChE


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