This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: thoughts about exception-handling requirements for kprobes
- From: Keshavamurthy Anil S <anil dot s dot keshavamurthy at intel dot com>
- To: Richard J Moore <richardj_moore at uk dot ibm dot com>
- Cc: systemtap at sources dot redhat dot com
- Date: Fri, 17 Mar 2006 13:50:57 -0800
- Subject: Re: thoughts about exception-handling requirements for kprobes
- References: <OFFFD05E79.21688AA2-ON8025712C.0052DE26-8025712C.0057A4F8@uk.ibm.com>
- Reply-to: Keshavamurthy Anil S <anil dot s dot keshavamurthy at intel dot 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