Re: thoughts about exception-handling requirements for kprobes

[fche@redhat.com (Frank Ch. Eigler)]

richardj_moore wrote:

> I've been thinking about the need for exception-handling [...]
> Cases 1 & 4
> The expected exceptions in user pre- and post-handlers are easy to deal
> with in a way that performs well: this is via a setjmp/longjmp mechanism.
> [...]

Right.

> It would seem better to have kprobes put a wrapper around setjmp
> (ksetjmp) and issue the longjmp directly. kprobes could also
> maintain a maxfault counter for the probe so that we can exit
> recursive fault situations.

Sure.  Perhaps the "kprobe" struct could get a jmpbuf field that could
be initialized using a call from within the pre/post handler.  The
default kprobes fault handler could check whether this field was set,
and if so, just longjmp to it.

> [...] Could we exploit if from systemtap?

Certainly - the standard probe prologue/epilogue could hook into it
just inside the lock/unlock sequence.  Given the data in the context
(such as last_stmt), it could synthesize an error message to at least
place blame at the right source-level point.

> How about using a try-catch semantic [...]

If necessary, some nested structure like that could be put also into
the scripting language.  But if all we want is general crash
protection, then the single implicit try/catch around the entire
handler block may well be enough.


- FChE