This is the mail archive of the
systemtap@sources.redhat.com
mailing list for the systemtap project.
Re: architecture paper draft
- From: "Stephen C. Tweedie" <sct at redhat dot com>
- To: Richard J Moore <richardj_moore at uk dot ibm dot com>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, systemtap at sources dot redhat dot com
- Date: Fri, 11 Feb 2005 11:48:23 +0000
- Subject: Re: architecture paper draft
- References: <OF9437CE08.5E1061F1-ON00256FA4.0081F171-00256FA4.00828C95@uk.ibm.com>
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