PATCH: vm area for uprobes SSOL

[Jim Keniston]

On Thu, 2007-03-22 at 18:00 -0700, Roland McGrath wrote [elsewhere]:
[Jim said:]
> > We'll post the patch as soon as we've done that testing and we get (and
> > address, if necessary) Dave's review.  If you wanna see it before then,
> > we can post what we have.
> 
> Please do.  Posting something with a "still buggy or unfinished" disclaimer
> is always fine, and the more often and earlier the sharing the better.
> This work in particular has several components that can be reviewed and
> discussed independently.
> Thanks,
> Roland
> 

This patch, by Prasanna Panchamukhi, replaces the out-of-line
single-stepping mechanism for the i386 version of uprobes.  The
single-stepped instruction must reside in the probed process's address
space.  To store this instruction-copy, we used to allocate space in the
thread's stack vm area, beyond TOS, but that introduced a security
problem (temporarily executable stack) and wasn't portable.  Now we
allocate a separate 1-page vm area and put the instruction-copies there.

Per Roland's request, we are posting this patch even though it has some
rough edges.  It seems to work as expected, but it needs some cleanup.
Here are Dave Hansen's first-pass comments on the vma-allocation code:
-----
I'd probably like to see a few things get cleaned up, like the calling
conventions for arch_setup_special_page() (should use ERR_PTR()) and the
storage of stuff in the mm_context which is pretty redundant.  The
completely separate code path when the VDSO is configured off also isn't
good, but I"m sure you can clean that up.  But, as a basic approach, it
should work.
-----
This patch applies atop the 3 patches I posted here:
http://sources.redhat.com/ml/systemtap/2007-q1/msg00587.html

Comments welcome.
Jim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uprobes-singlestep-out-of-line-lru.patch
Type: text/x-patch
Size: 21742 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20070323/3d2e73f0/attachment.bin>