This is the mail archive of the systemtap@sources.redhat.com mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: architecture paper draft






- -
Richard J Moore
IBM Advanced Linux Response Team - Linux Technology Centre
MOBEX: 264807; Mobile (+44) (0)7739-875237
Office: (+44) (0)1962-817072

"Stephen C. Tweedie" <sct@redhat.com> wrote on 11/02/2005 11:48:23:

> Hi,
>
> On Thu, 2005-02-10 at 23:45, Richard J Moore wrote:
>
> > > > 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 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.
>
> Fair enough.
>
> >  So,
> > we hooked the front-end of the page and general protection fault
handlers
> > so that we could hide these events from the kernel.
>
> You mean, detect that you're already in int3, and special-case that?
> Sounds sane.
>
> >   When I use the term
> > "fault" I mean generate the exception
>
> On 4g/4g there *IS* no exception when you access user-space.  It's all
> done via page-table walking.  You can't get it directly from kernel
> space, because with 4g/4g the kernel is running in a completely
> different address space. So the requirements about being IRQ- and
> spinlock-safe apply even if the user-space data is readily available and
> doesn't require paging in.
>
> > ; 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.
>
> With 4g/4g the data isn't even there to be touched.  You just can't
> assume that you can bypass the copy_*_user macros in general.  It only
> works for some special cases, like non-4g4g x86.  (Admittedly, that's a
> rather large and important subset of the general case!)
>
> >  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.
>
> Which is only a valid concept if the user-mode access uses exceptions.
> On 4g4g, it goes via rw_vm() instead, which is more like ptrace than
> anything else --- it's effectively a manual lookup into a different
> address space.  If it requires paging in, then the lookup eventually
> achieves that via a direct handle_mm_fault() call, not via any
> exceptions.
>

Ah yes, I see your point now. We need to do things differently for crossing
the user/kernel boundary. All we need is conditional access. If the page
mapping in user space doesn't exist or is paged out then we would softly
fail the probe handler. I'm going to have to think about how we should do
this in the 4g/4g scenario.

Thanks for the clarification.

Cheers
Richard



> Cheers,
>  Stephen
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]