Re: thoughts about exception-handling requirements for kprobes

[Keshavamurthy Anil S <anil.s.keshavamurthy@intel.com>]

On Thu, Mar 09, 2006 at 07:57:18AM -0800, Richard J Moore wrote:
> 
>    I've been thinking about the need for exception-handling and how the
>    current implementation has become a little muddled.

Here is my thinking on this kprobe fault handling...
Ideally we want the ability to recover from all 
the page faults happening from either pre-handler 
or happening from post-handler transparently in the 
same way as the normal kernel would recover from 
do_page_fault() function. In order for this to happen, 
I think we should not be calling pre-handler/post-handler
by disabling preempt which is a major design change.
Also in the current code if fixup_exception() fails to
fixup the exception then falling back on the normal
do_page_fault() is a bad thing with preempt disabled.

I was thinking on this issue for the past several days 
and I believe that currently we are disabling preempt 
before calling pre/post handler, because we don;t 
want the process to get migrated to different CPU 
and we don't want another process to be scheduled 
while we are servicing kprobe as the newly scheduled
process might trigger another probe and we don;t 
have space to save the kprobe control block(kprobe_ctlbk) 
info, because we save kprobe_ctlbk in the per cpu structure.

If we move this saving kprobe_ctlbk to task struct then
I think we will have the ability to call pre/post-handler
without having to disable preempt and their by any faults
happening from either pre/post handler can recover transparently
in the same way as the normal kernel would recover.


Any comments on the above idea? I still don;t have a good
solution for unregisteration of kprobes if we move to above
design.


>    2) Unexpected exception, user pre-handler.
> 
>    here the pre-handler has either a bug or is debugging a badly damaged
>    environment.  Let's  not  forget  that  the latter environment is very
>    import to
>    cater for as best we can.
>    The  response  should  at  the  very  least  be  to quietly cancel the
>    pre-handler.
>    It's  also  conceivable  that one might want to intercept this to free
>    off any
>    locks and put out an explanatory message.

Yes, it would be nice to recover even from a buggy pre/post_handler and 
disable the buggy probe completly with some explanatory message.


Thanks,
Anil