Re: thoughts about exception-handling requirements for kprobes

[Prasanna S Panchamukhi <prasanna at in dot ibm dot com>]

On Fri, Mar 17, 2006 at 01:50:57PM -0800, Keshavamurthy Anil S wrote:
> 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.
> 

Kprobes user-specified pre/post handler are called within
the interrupt context and if we allow page faults while within
user-specified pre/post handler, then it might sleep.
Is is ok to sleep while within the interrupt handler?

Thanks
Prasanna
> 
> 
> >    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

-- 
Prasanna S Panchamukhi
Linux Technology Center
India Software Labs, IBM Bangalore
Email: prasanna@in.ibm.com
Ph: 91-80-51776329