thoughts about exception-handling requirements for kprobes
Keshavamurthy Anil S
anil.s.keshavamurthy@intel.com
Fri Mar 17 21:51:00 GMT 2006
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
More information about the Systemtap
mailing list