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


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.

Cheers,
 Stephen


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