RE: [RFC]-Approaches to user space probes ->>> Kprobes and kretprobes

["Keshavamurthy, Anil S" <anil dot s dot keshavamurthy at intel dot com>]

>Hi -
>
>anil.s.keshavamurthy wrote:
>
>> [...]  I am not an expert in Java or Java probes, but before we lock
>> down this approach I am suggesting that if possible we get feedback
>> from JVM gurus too.
>
>OK, but to involve them at this stage, we have to first formulate the
>issue in a form they can understand.  Beyond asking them to add a few
>hooks into their various interpreters (similarly to dtrace), how do
>you think they might be impacted?

All I trying to see is to get more expertise here to look at our current

user probes proposal.

>
>
>> [...] having a counter to count the missed probe does not solve the
>> problem here.
>
>Which problem?  That this can occur (with some low probability?)?
>That it may be difficult to detect after occurrence?  That it may
>be hard for a user to work around (rerunning may not work)?
>
>> [...] 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. There are chances that Kprobes handler are called but the
corresponding
Kretprobe handler are not called(this could be due to no free kretprobe
instance available).
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. One such
example is Josh's script.
I am concerned that people might come up with such kind of scripts and
get wrong results.

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


-Anil