[RFC] Design + prototype: Multiple handler sets per probe address

[Frank Ch. Eigler]

Hi -


On Fri, Apr 01, 2005 at 09:34:28AM -0500, Ananth N Mavinakayanahalli wrote:
> Here is a design to support "Mulitple handler sets per address". I have 
> also put in the i386 implementation based on this design.

Thank you.


> 2.4.2.3 Fault handlers
> 
> Fault handlers are called in sequence _until_ one of them handles
> the fault (returns non zero). Once a fault is handled, no other
> handlers are called.

This sounds wrong.  If at all possible, the code should arrange to
call only the single fault handler that corresponds to the current
specific kprobe being handled.

Keep in mind that one use for this feature is for running several
independent systemtap sessions at the same time.  They should remain
as isolated from and ignorant of each other as possible.  In
particular, one should not be told that the other has happened to
cause a fault.  Similarly, one client should not be able to prevent
another client from getting its probe handler called, by returning a
"success" indication of its own.


> [...]
> - Multiple handlers cannot be registered at a location that already
>   has a jprobe registered. In other words, to register a jprobe,
>   no other handlers must be registered at that address and 
>   vice-versa.

Could you be more specific about why this limitation needs to exist?
To what extent does the execution of a jprobe handler mess up the
possibility of also running a kprobe handler at the same spot?


> - We currently silently disarm the kprobe if we are recursing 
>   and ignore it. Do we have to change that?

Reentrancy control is likely to remain essential.  It would be nice if
some counter was kept of the number of times that a probe was skipped
due to reasons like this, so that ultimately a user become aware that
something went wrong.


- FChE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20050401/33825db0/attachment.sig>