Re: kprobe fault handling

[Jim Keniston <jkenisto at us dot ibm dot com>]

On Tue, 2006-02-07 at 09:51, Martin Hunt wrote:
> On Tue, 2006-02-07 at 09:31 -0800, Jim Keniston wrote:
> [...]
> > > > And that's it. kprobe_fault_handler returns 0.  No call to
> > > > fixup_exceptions()!  So do_page_fault() will have to do the fixups, but
> > > > first it will print nasty might_sleep warnings and maybe actually sleep!
> > 
> > You have the right idea of running fixup_exceptions() in the fault
> > handler, to prevent do_page_fault() from attempting its demand-paging
> > stuff.  I just think it's OK to have the user's fault handler, rather
> > than kprobe_fault_handler, run fixup_exceptions.
> 
> I think if the user's fault handler does not handle the page fault,
> kprobes should attempt to do so. Returning without handling the page
> fault could leave the system in a bad state. So your proposal would mean
> it is necessary to specify a fault handler for any kprobe that might
> attempt user-space access or otherwise trigger a page fault, otherwise
> the system could crash.

I just had a long chat with Richard Moore about this whole topic.  I
agree with you on this, and I think Richard would, too.

So unless there's a user-specified handler and that handler specifies
(by returning 1) that it has handled the exception,
kprobe_fault_handler() should run fixup_exception(), right?

Now I'm looking, later in that function, at the code (on i386) where we
handle an exception while single-stepping.  I don't think
resume_execution() is the right thing to do here.  We haven't
successfully executed the probed instruction, and the eip still points
at that instruction, right?  I think we're just hosed at this point. 
Comments?

> 
> Any more importantly, fixup_exception() and all the exception table code
> are currently not exported so cannot be called from a module.

It's hard to argue with that. :-)

> 
> Martin

Jim