Re: architecture paper draft

[Richard J Moore <richardj_moore at uk dot ibm dot com>]

"Stephen C. Tweedie" <sct@redhat.com> wrote on 10/02/2005 23:15:58:

> Hi,
>
> On Thu, 2005-02-10 at 17:39, Richard J Moore wrote:
>
> > So it looks like we are on the same page :-)
> >
> > It seems to me that we need to use our original technique, which was to
> > front-end page fault during execution of the probe handler and use
direct
> > access to use space (e.g. in-line asm MOV System,User).
>
> What do you mean by "front-end page fault" here?  Until you actually
> execute the probe, you don't know which memory to fault.
>
> I'd really like to see an example of just what you're trying to achieve
> here, btw.  I can see all sorts of problems that _might_ occur during
> uaccess in a probe, but if it turns out the examples you have in mind
> are all benign, then we may just be getting tied in knots for no reason.

I think the may be some language misalignment here. The probe handler runs
as an extension to the trap 3 interrupt handler. In that context one cannot
allow a fault - page or otherwise - and expect the kernel not to panic. So,
we hooked the front-end of the page and general protection fault handlers
so that we could hide these events from the kernel.  When I use the term
"fault" I mean generate the exception; I don't mean cause a page-in. All we
can hope to do is avoid panics when the probe handler touches something
that's paged-out. A call-back to the probe handler allows it to take some
custom action, the default being to exit the probe handlers and return
control to the system as if the probe hadn't been installed.




>
> --Stephen
>